This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
You mean a real life example of why do you need the JNDI ENC when defining a reference to another EJB / resource / persistence unit / etc.?
The below post is just my point of view - it doesn't have to (in any matter) reflect how it really was.
I guess it's because of the backward compatibility.
I can just suspect that in former days there wasn't an easy way to access the 'injected' EJB reference from another EJB. That's why they need to define (in DD) in what JNDI location the reference will be available for the given EJB.
Right now you can still define in what ENC JNDI context you would like to put your injected EJB reference to be able to look it up directly in one of your business methods. Then again, I guess that nowadays you can use the @EJB, @Resource, etc. (not mentioning the CDI!) so I can't think of of any real use of the directly accessing the ENC using JNDI aside from integrating with some legacy code.
Did it help you in any way?
OCP Java SE 6 Programmer, OCM Java SE 6 Developer, OCE Java EE 6 JSPSD, OCE Java EE 6 EJBD, OCE Java EE 6 JPAD, Spring 3.0 Core Professional.
That could have been better worded in my other post. In EE6, each application (a .ear application for example) will have a separate java:app namespace, each module (ex: a EJB jar module or a web app module) a separate java:module namespace and each component (for example a EJB) will have a java:comp namespace.
Ok, and just to have the full picture, let's fully clarify this. According to:
EJB 3.1 spec wrote:A .jar file in WEB-INF/lib that contains enterprise beans is not considered an independent Java EE “module” in the way that a .war file, stand-alone ejb-jar file, or an .ear-level ejb-jar file is considered a module. Such a .jar does not define its own module name or its own namespace for ejb-names, environment dependencies, persistence units, etc. All such namespaces are scoped to the enclosing .war file. In that sense, the packaging of enterprise bean classes in a WEB-INF/lib .jar is merely a convenience. It is semantically equivalent to packaging the classes within WEB-INF/classes.
EJB 3.1 spec wrote:In a .war file, there is a single component naming environment shared between all the components (web, enterprise bean, etc.) defined by the module. Each enterprise bean defined by the .war file shares this single component environment namespace with all other enterprise beans defined by the .war file and with all other web components defined by the .war file. The Bean Developer should be aware of this name scoping behavior when selecting names of environment dependencies for enterprise beans packaged within a .war file. Unlike enterprise beans packaged in an ejb-jar file outside a .war, names of environment entries defined by an enterprise bean inside a .war can clash with names defined by other components. Likewise, enterprise beans packaged in a .war file have visiblity to all environment entries defined by any other components in the .war file, including any entries defined within web.xml.
So if you wrap your EJB's with web application in *.war file, then the java:comp/env namespace will be used for all EJB's within the *.war file, but if you would wrap the application as an independent ejb-jar *.jar file, the java:com/env namespace will be a private space for each EJB.