I know roughly what this construction does: it creates a SomeType EJB and injects the object into another EJB.
@EJB(name=\"name1\")
SomeType someVariable
The @EJB
annotation (and @Resource
, @WebServiceRef
, etc.) serves two purposes:
@EJB(name="myEJB")
creates a reference java:comp/env/myEJB
. If you annotate a field and do not specify a name, then it creates a reference java:comp/env/com.example.MyClass/myField
.How the reference is resolved varies, independent of whether the reference is being resolved for a lookup("java:comp/env/myEJB")
or due to injection:
lookup
attribute requires a JNDI lookup to resolve the target.mappedName
, which is specified to be vendor specific. This is usually implemented by performing a lookup.beanInterface
or the field type) is only implemented by a single EJB in the application, then the EJB specification requires that it fall back to that.java:comp/env/myEJB
might cause a lookup of myEJB
in the server namespace).According to this link, basically this annotation enables EJB to lookup external EJBs relatively to its context. Usually, there are more elegant ways to do that.
Miljen Mikic's answer gave me an idea about the possible answer. If anyone who knows about JNDI reads this, please tell me if this is sane, as I'm basically guessing here.
Basically, there are 2 ways to look into the JNDI tree: either via a global path (/some/proprietary/path/my/bean) and via your program's environment (java:comp/env/my/bean). The idea is that you create references from the global path to you local environment, and then lookup the components from there.
So @Ejb(name="java:comp/env/my/bean",mappedName="/some/proprietary/path/my/bean") would create this reference from java code (without descriptor xml file).
This means @Ejb(name="java:comp/env/my/bean") is on its own a no-op: It copies a reference onto itself. It might hava as side effect the fact that you application server now knows at compile time that this reference is required,but that's about it.
As for the bonus question: Yes, the two annotations regarding transactions are repeating defaults: The default TransactionManagementType is CONTAINER (vs BEAN) and the - default - TransactionAttributeType REQUIRED simply states that if the bean is called within a transactional context the transaction is continued, otherwise a new transaction will be initiated (as opposed to, for example REQUIRES_NEW which will always create a new tx). This is actually in detail not as trivial as it sounds Cf. the EJB 3.1 spec:
"13.3.7 Specification of the Transaction Attributes for a Bean’s Methods
The Bean Provider of an enterprise bean with container-managed transaction demarcation may specify the transaction attributes for the enterprise bean’s methods. By default, the value of the transaction attribute for a method of a bean with container-managed transaction demarcation is the REQUIRED transaction attribute, and the transaction attribute does not need to be explicitly specified in this case.[...]"