The container injects entries from the environment into the enterprise bean's fields or methods as specified by the bean's metadata annotations or the deployment descriptor.
The container makes the environment naming context available to the enterprise bean instances at runtime. The enterprise bean's instances can use the EJBContext lookup method or the JNDI interfaces to obtain the values of the environment entries.
In general, lookups of objects in the JNDI java: namespace are required to return a new instance of the requested object every time. Exceptions are allowed for the following:
� The container knows the object is immutable (for example, objects of type
java.lang.String), or knows that the application can't change the state of the object.
� The object is defined to be a singleton, such that only one instance of the object may exist in the JVM.
� The name used for the lookup is defined to return an instance of the object that might be shared. The name java:comp/ORB is such a name.
In these cases, a shared instance of the object may be returned. In all other cases, a new instance of the requested object must be returned on each lookup. Note that, in the case of resource adapter connection objects, it is the resource adapter's ManagedConnectionFactory implementation that is responsible for satisfying this requirement.
Each injection of an object corresponds to a JNDI lookup. Whether a new instance of the requested object is injected, or whether a shared instance is injected, is determined by the rules described above.
@EJB ProcessPaymentLocal processPayment;
The specification isn't very detailed in terms of exactly how the EJB container should resolve this reference. To give you a feel for how this process works, let's see how the JBoss application server resolves this reference:
1. The only possible identifier for this EJB reference is the business interface type. The application server first looks for a unique EJB in the referencing EJB's EJB-JAR deployment that uses ProcessPaymentLocal as its local or remote interface. If more than one EJB uses the same business interface, it throws a deployment exception.
2. If the EJB-JAR is deployed as part of an Enterprise ARchive (.ear), it looks in other EJB-JARs for a unique EJB that uses the ProcessPaymentLocal interface. Again, if more than one EJB uses the same business interface, it throws a deployment exception.
3. If the EJB reference is not found in the .ear file, it looks for it in other global EJB-JAR deployments. If the beanName( ) attribute is specified, then JBoss uses the same search process, but it uses the beanName( )'s value as an additional identifier. If the mappedName( ) attribute is specified, then no search process is performed. The application server expects that a specific EJB is bound into the global JNDI under the mappedName( )'s value.
If the beanName( ) attribute is specified, then JBoss uses the same search process, but it uses the beanName( )'s value as an additional identifier.
However the (Resource) annotation can be also used for e-mail server resources, environment entries, Orb references or even EJB instances.
Originally posted by Mihai Radulescu:
even EJB instances.
The Bean Provider uses the EJB annotation to annotate a field or setter property method of the bean class as a target for the injection of an EJB reference. The reference may be to a session bean�s business interface or to the local home interface or remote home interface of a session bean or entity bean.
Originally posted by Mihai Radulescu:
can I use this kind of look up from a POJO client ? In this case the String argument for the lookup method will be the JNDI name descibed by you in the previous posts.
I keep trying this but I get always a NammingException.
Enterprise bean�s name. A logical name is assigned to each enterprise bean in the ejb-jar file. There is no architected relationship between this name and the JNDI name that the Deployer will assign to the enterprise bean. The Bean Provider can specify the enterprise bean�s name in the ejb-name element. If the enterprise bean�s name is not explicitly specified in metadata annotations or in the deployment descriptor, it defaults to the unqualified name of the bean class.