whats the use of ejb reference

[manish ahuja]

Hi All
I would like to know whats the use of ejb-reference . How does it actually simplify things.
I have read it is used for intra bean calls. but the way it is done there seems no difference in the way a normal look up is done . We have to do a JNDI look up in the very same way as we do it from web clients like a servlet.

normally from a client we access the JNDI for ejb home reference
public class ABean implements SessionBean {
public void businessMethod(...) {
...
InitialContext namingContext = new InitialContext();
Object ref = namingContext.lookup("java:comp/env/ejb/myBean");
BHome home = (BHome)PortableRemoteObject(ref);
B bean = home.create(pk);
...
}
}
is this "java:comp/env/" necessary cant i just say
Object ref = namingContext.lookup("ejb/myBean");
in the above code. As far as i know we can (correct me if i m wrong)
So how does ejb-ref tag simplify things.
Normally from any client we access the jndi as shown above so how does the JNDi access differ if say the client access the EJB is a local client say an SLSB.
So how is a local client different in terms of JNDI access not mentioning the local interfaces & call by reference advantage.
Why we need an ejb-ref tag for clients which are local for an EJB.
or is it that we require an ejb-ref tag for every ejb we deploy to give it a JNDI name so client can look up on that name.

Kidly clarify

Rgrds

[Janne Karhu]

I think the reason to use ejb-refs in bean code is that the bean provider supposedly does not know the actual JNDI location for any specific bean. The deployer does, and thus fills the actual JNDI name using the container supplied tools. (Everybody please correct me if I am wrong).
In practise, however, I've always used the actual JNDI names (since bean provider/app assember/deployer are all ME).

[Reid M. Pinchback]

You are correct, it is to allow JNDI hookups to be specified at deployment time. It is important for multiple reasons. The way the global JNDI tree is managed is completely different from how the specialized JNDI context is provided to the bean. I've seen situations where JNDI paths I've written for one server won't even work on another server. Add to that the fact that JNDI is a shared namespace... the global path you wanted to use may already have been allocated to some other application on the server. Factor in additional issues like LDAP security, and you soon find that dealing with the JNDI tree is a pretty unpredictable problem space for the bean provider.
The local JNDI context is very important for allowing the bean provider's code to work in multiple deployment environments without change. Even if you aren't worrying about selling your beans, the local context is still an important way to help your code be portable across servers. I once had a project were we started on WebLogic, and half way through the project management decided they couldn't cut an acceptable marketing/licensing deal with BEA. End result: we had to shift JBoss in one week. We weren't using local JNDI contexts, and we had to track down and fix all the JNDI references. If the situation had changed and WebLogic was back on the plate, we'd have had to go back and 'unfix' them again.

[Goan Balchao]

Yes, and java:comp/env/ejb is default. You need not use it explicitly. But any node under java:comp/env/ejb must be specified.

[Todor Mollov]

java:comp/env subcontext is where the bean begins navigating when he want to look something up.

[manish ahuja]

Hi Reid

Could you ellaborate a bit on what is local jndi contexts & global jndi contexts

Rgrds

[Janne Karhu]

Global JNDI context -> everybody (all the code which can access the JNDI server) basicly sees the contents (e.g. objects that implement home interfaces).
Local JNDI context -> only the bean in question sees the contents written to the deployment descriptor, and the JNDI entries do not exist outside the bean. For example, different beans in the same server can all have their own environment entries with the same name (and subcontext), but they all see a different value (providing that the app assember/deployer has set the different values).

Originally posted by manish ahuja:
Hi Reid

Could you ellaborate a bit on what is local jndi contexts & global jndi contexts

Rgrds

[Reid M. Pinchback]

Yup. Also to clarify, there is nothing "official" about the wording I used, I was just trying to distinguish between the context that the EJB container populates for the bean, versus the complete JNDI tree you see as a remote client. What I was calling "local" is what HFE calls "the bean's special JNDI context" and I've also seen referred to as the "ENC" - environment naming context.

[Vishwa Kumba]

Good thread and good explanations!