Declaring @Resource and @EJB at the class level in Java EE6

Is there any situation still ( given that Java EE6 has java:global/, app/, module/ naming standards) that necessitates declaring EJBs or Resources like the example below?

@EJB (name = "ejb/PlaceBid", beanInterface = PlaceBid.class)
public class ActionBazaarBidControllerServlet extends HttpServlet {

}

Looking up PlaceBid in the helper class used 开发者_Go百科by ActionBazaarBidControllerServlet

PlaceBid placeBid = (PlaceBid)context.lookup("java:comp/env/ejb/PlaceBid");

---

The java:comp/env/ namespace is sometimes a little understood feature. This namespace corresponds to what is called the Enterprise Naming Context (ENC).

It's like a private "hashmap" associated with each component, with the entire web module being treated as one component and individual EJB beans each being components as well.

You use this private namespace mostly for aliasing purposes. If you map something under "ejb/PlaceBid", then all (helper) code can use "ejb/PlaceBid" and at one global location (the servlet in this case, but it could also be XML) you can determine what is exactly mapped to it. If all code went directly to java:global/... then there might be dozens of hardcoded dependencies to this name.

So, you would use this if you need the extra redirection.

---

Some other things to note:

1. With the EJB SessionContext you can reference this namespace directly, as-in:

PlaceBid placeBid = (PlaceBid)sessionContext.lookup("ejb/PlaceBid");

Here "ejb/PlaceBid" is a relative name into the ENC.

2. As mentioned, the ENC is private for each component. Different EJBs can have a given relative name mapped differently. context.lookup("java:comp/env/ejb/PlaceBid") can thus return something different depending on from which component you make the call.

3. Historically, the ENC predated what we now call injection. In a way, when you specified a mapping in XML, you 'injected' something into the private "hashmap" associated with that component. The modern version injects into fields, constructors or properties (setters), but the old version injected into 'keys'.

Even in EJB3.1, the historical 'injection' mechanism is still active under the hood. If you perform a seemingly normal injection using @EJB on a field, then this also automatically creates an entry in the JNDI ENC. E.g.

package test;

@Stateless
public class MyBean {

   @EJB
   private MyService myService;

}

In this case, whatever is injected into myService is also stored in the ENC under name java:comp/env/test.MyBean/myService. To complete the link with the @EJB annotation you used on the Servlet: you can optionally use the name attribute to specify the name under which the reference is stored in the ENC:

@Stateless
public class MyBean {

   @EJB(name = "ejb/PlaceBid")
   private MyService myService;

}

A little counter-intuitive, but in most cases the name attribute here is thus not something that points to a source where the object to be injected is taken from, but it's used as a target in the ENC to inject into.

---

Declaring a reference using a class-level annotation and declaring a reference using a java:module, java:app, or java:global name are distinct features.

You would use a class-level annotation to declare a reference if you don't need injection but you don't want to use XML.

You would use a java:module, java:app, or java:global name (regardless of how the reference is defined) if you want multiple components in the module, app, or server to have access to the same reference. For example, so that you are only required to define a binding for the reference once rather than repeating the same binding information for each identical binding in the module (or in the app or for all apps in the server).