When I'm trying to create a new EJB
3.0 project in eclipse, it asks if I want to create a client jar also. What
purpose does this client jar serve?
An EJB client JAR file is an optional JAR file that can contain all the class files that a client program needs to use the client view of the enterprise beans that are contained in the EJB JAR file. If you decide not to create a client JAR file for an EJB module, all of the client interface classes will be in the EJB JAR file
My ejbmodule is added as a part of the
EAR file. So do I really need this
client jar?
You do not really need the EJB Client it just provides an easier packaging to use the EJBs from a client.
Do I need to create both local and
remote interfaces? Or just remote
interfaces will do?
If all your EJBs are in the same EAR then you can use local interfaces, if not you need remote interfaces. Local interfaces are more efficient, the calls are done be reference.
Some Containers (i.e. WebSphere) will optimize this at runtime for you and automatically call local interfaces if it is possible.
I decided to keep all the interfaces
in a project called projCommon and the
bean definitions in projApps. The
remote interfaces which the bean
classes implement are in projCommon.
So projApps is dependent on
projCommon.
I would keep my projects organized by functional areas. Make local calls within the functional areas and remote ones outside of the functional areas, This allows you to later split the functionality to be deployed on different servers to scale it. It also keeps the code more modular. This also avoids any circular dependencies.
How exactly are EJB's directly
injected?
The how it works does not matter, That is going to be done by the container. The whole point of J2EE is to abstract out the how.
As per http://www.developer.com/print.php/3650661:
EJB 3 containers provide the facilities to inject various types of resources into stateless session beans. Typically, in order to perform user tasks or process requests from client applications, the business methods in the session bean require one or more types of resources. These resources can be other session beans, data sources, or message queues.
The resources that the stateless session bean is trying to use can be injected using annotations or deployment descriptors. Resources can be acquired by annotation of instance variables or annotation of the setter methods.