Java Reference
In-Depth Information
EJBs in an application depend on other EJBs and resources, imagine the lines of repetitive
JNDI lookup code littered across an average business application! To make matters worse,
before Java EE 6, JNDI resources didn't have standard lookup names with every Enterprise
server binding resources in JNDI with different names. So JNDI lookup names weren't
portable across servers and the JNDI names of resources weren't always that obvious to
figure out, especially for local resources that used the arcane java:comp/env/ prefix.
The good news is that except for certain corner cases, you won't have to deal with JNDI
directly in EJB 3. EJB 3 hides the mechanical details of JNDI lookups behind metadata-
based DI. DI does such a great job in abstraction that you won't even know that JNDI look-
ups are happening behind the scenes, even for remote lookups. This abstraction is possible
in part to standard JNDI lookup names, especially for EJBs, which are portable across all
EE servers. In the next section we'll look at this standard and see how EJB names are as-
5.2.2. How EJB names are assigned
To make EJB JNDI lookups portable across all Java EE servers, the following portable
JNDI name has been standardized:
Where <namespace> , <module-name> , and <bean-name> are required and always
present, [app-name] and [!fully-qualified-interface-name] may be op-
tional. Let's take a look at each part of this portable JNDI name and see how they get their
The Java EE server's naming environment is divided into four namespaces, with each
namespace representing a different scope. Table 5.5 describes these namespaces.
Table 5.5. Java EE naming environment namespaces
Lookups in this namespace are scoped per component. For example, an EJB is a component, so
each EJB in a JAR file gets its own unique java:comp namespace. This means both AccountEJB
Search WWH ::

Custom Search