Finding resources

[ravinderSingh singh]

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?

Thanks

[Valentin Tanase]

Because it's using the Environment Naming Context (ENC); that's the meaning of "java:comp/env/".
Regards.

[ravinderSingh singh]

What's an environment naming context (ENC)?

[Filip Pas]

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

[Valentin Tanase]

Hi Ravinder,

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.

Hi Filip,

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.

[Roger Chung-Wee]

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

[Filip Pas]

In order to resolve those conflicts the application deployers will specify the jndi-name in a similar way: myapplication/ejb/MyEjb.

So you agree the difference is made in the server-specific deployment descriptor and not the server-agnostic deployment descriptor then?

[Arun]

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:

InitialContext context = new InitialContext();
Object c = context.lookup("Advisor");
 
AdviceHome home = (AdviceHome) PortableRemoteObject.narrow(c, AdviceHome.class);
 
Advice advisor = home.create();

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.