Every application you deploy typically has an environment context. In your deployment descriptor you specify by which name you will lookup a resource. If you wrote ejb/MyEjb you'll lookup the ejb using java:comp/env/ejb/MyEjb. The actual value used for a lookup is resolved using a server specific deployment descriptor. There it says that MyEjb links to for example myapplication/ejb/MyEjb. This way every application can specify whatever name it likes to perform the lookup on and that name gets linked to the actual jndi name. It allows (almost) identical deployment units with different server-specific deployment descriptors. Meaning you'll have two applications that use exactly the same code but use totally different resources.
Anyway that's what I think the environment context is. I could be wrong though
ENC is the default JNDI context for making resources available to the bean at runtime. It basically replace the EJBContext.getEnvironment() used in ejb 1.0 and is defined by the J2EE specification. As you might guess, by default ejb 1.1(and higher) will bind DataSources, JavaMail, JMS resource factories and EJBHome remote interfaces to ENC.
There it says that MyEjb links to for example myapplication/ejb/MyEjb. This way every application can specify whatever name it likes to perform the lookup on and that name gets linked to the actual jndi name. It allows (almost) identical deployment units with different server-specific deployment descriptors. Meaning you'll have two applications that use exactly the same code but use totally different resources.
I personally believe that ENC won�t resolve naming clashing issue. If one application deploys a bean to ENC then another apps won�t be able to deploy beans with the same name. I believe that the container will throw a NameAlreadyBoundException. In order to resolve those conflicts the application deployers will specify the jndi-name in a similar way: myapplication/ejb/MyEjb. Regards.
When locating resources, such as a DataSource, why is the jndi name of the resource prefixed with java:comp/env?
For example, given a DataSource jdbc/datasource why do we use java:comp/env/jdbc/datasource instead of just jdbc/datasource?
All EJBs have a default JNDI context called the environment context. The default context exists in the name space called "java:comp/env" and its subdirectories. When the bean is deployed, any beans it uses are mapped into the subdirectory "java:comp/env/ejb".
Furthermore, The EJB specification recommends that all resource manager connection factory references be organised in the subcontexts of the bean�s environment, using a different subcontext for each resource manager type. So, typically you get this:
java:comp/env/jdbc - for JDBC DataSource references java:comp/env/jms - for JMS connection factories java:comp/env/mail - for JavaMail connection factories java:comp/env/url - for URL connection factories
Hello All, I did a simple session bean and used Sun's EJB RI server to deploy the bean under the name "Advisor". here's how the look up code looks like:
I did not use "java:comp/env.." or anything like that to deploy or to look up "Advisor". I am assuming RI put "Advisor" in the JNDI tree under "java:comp/env/ejb". For the look up, am I correct in saying that I made java search down the JNDI tree looking for somethin called "Advisor"?
If someone had named a jdbc datasource under the same name "Advisor" (but under the default java:comp/env/jdbc) then is it possible that the datasource could have been returned instead of the ejb home that I was expecting??
Thanks in advance.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop