Krish,
Your discussion is very interesting and informative, yet I was a little
confused by your assertion that all local ejb references are handled
differently than remote references. The EJB 2.0 spec has this statement:
20.3.1.1 EJB reference programming interfaces
The EJB specification recommends, but does not require, that all references
to other enterprise
beans be organized in the ejb subcontext of the bean’s environment (i.e.,
in the
java:comp/env/ejb JNDI context).
And, in that same section, the spec states that :
20.3.1.2 Declaration of EJB references in deployment descriptor
An EJB reference is scoped to the enterprise bean whose declaration
contains the ejb-ref or
ejb-local-ref element. This means that the EJB reference is not accessible
to other enterprise
beans at runtime, and that other enterprise beans may define ejb-ref and/or
ejb-local-ref ele-ments
with the same ejb-ref-name without causing a name conflict.
While the ejb remote and local references are required to be declared by the
Bean Provider and are scoped to that bean's naming context (java:comp/env), the
spec still does not require that they be looked up using java:comp/env/ejb.
I was momentarily confused by the first statement (20.3.1.1), and maybe
appserver writers are, too. It appears that the spec did not require that ejb
references be bound to java:comp/env. But that is not what it is saying.
The statement is that they recommend that ejb references (local and remote) be
bound to a subcontext named "ejb". Deployers could use a context named
"lord_of_the_rings" to store references if they wanted to, but it must be
rooted from java:comp/env.
Another point of confusion is how none-ejb clients lookup ejb references. In
Chapter 5 it states:
Chapter 5 Local, Remote, and Web Service Client Views
5.3 Local Clients
Session and entity beans may have local clients. A local client is a client
that is collocated in the same
JVM with the session or entity bean that provides the local client view and
which may be tightly cou-pled
to the bean. A local client of a session bean or an entity bean may be
another enterprise bean (a ses-sion
bean, entity bean, or message-driven bean) or a web component.
As I understand it, ejbs and web services must use java:comp/env to lookup
other ejbs and that local references for session and entity beans are available
to other ejbs. Web components (jsp's and servlets) may lookup local
interfaces if they are located in the same JVM, but other ejb clients
(applications and remote jsp's and servlets) must use the remote home
interfaces found in the global jndi bindings.
So, how does a servlet or jsp lookup a local interface? I do not recall (and
do not have the servlet/jsp spec handy) if java:comp/env is used by jsps and
servlets. But even if they are, I do not recall jsps needing a deployment
descriptor that would declare local ejb references. So how does a jsp/servlet
lookup local references?
Thanks,
Frank Gates
Geneva Project
Krishnan Subramanian wrote:
> Hemant,
>
> I know its hard when people argue that AppServer X supports it.
> Our response has been that it's a bug in X. And then the same
> people come back a few days later to claim AppServer Y supports
> it as well! And my response usually is: "Now you know it's a
> bug in Y as well!" *grin*
>
> But, given a lot of migrations (from X & Y ;) to our product,
> we've had to introduce a plug-in that lets these messed up
> JNDI calls work in our product (sometimes source code is not
> available). Its saved our customers some effort in the migration
> process and probably is the first time we've knowingly introduced
> a bug into our product.
>
> -krish
> Borland
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: 28 February 2003 12:18
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: how not to look up local Ejbs
> >
> >
> > A direct JNDI name lookup on the local interface does not
> > make much sense.
> > But when clients say app server X is supporting this, its
> > pretty difficult
> > to drive the point. Anyway we survived the temptation :-).
> >
> > cheers,
> > Hemant
> > www.pramati.com
> >
> > > All,
> > >
> > > Many EJB developers who are building applications based on
> > > the EJB 2.x specification seem to be making this (serious)
> > > mistake; and worse do not realize that their code is relying
> > > on an AppServer bug.
> > >
> > > The problem itself is a simple one:
> > >
> > > When looking up an EJB with local interfaces, developers use
> > > the physical JNDI name of the local enterprise bean in lieu
> > > of the specification defined environment naming context(ENC).
> > >
> > > For example: assume a local entity bean with fully qualified
> > > package name: com.mycompany.employee.ejb.EmployeeEjbHome
> > > and any unique local JNDI name (say): EmployeeEjb. This
> > > name could also be the fully qualified class name - which
> > > many seem to prefer.
> > >
> > > And the code developers tend to write to lookup this local
> > > bean from a caller (say another EJB / Servlet etc,.) is:
> > >
> > > javax.naming.Context jndiContext =
> > > new javax.naming.InitialContext();
> > > Object localRef = jndiContext.lookup("EmployeeEjb");
> > >
> > > Unfortunately, the above code is not right. The fact that it
> > > works in your AppServer would be an AppServer bug. Let me
> > > explain:
> > >
> > > There are two 'spaces' where you could register resources. One
> > > in the naming service (globally accessible) - and other in the
> > > environment naming context (ENC) of a bean. The ENC is private
> > > to that bean. So, while the underlying implementations are
> > > different, the API (JNDI) used to access both are the same.
> > >
> > > The distinguishing factor between the two - is that resources
> > > registered in the ENC begin with the prefix "java:comp/env/".
> > > And the Container 'knows' that any lookup performed with the
> > > "java:comp/env/..." prefix must be routed to the ENC of that
> > > bean, while any other would go to the naming service.
> > >
> > > To visualize things, you could think of the ENC as a cute little
> > > naming service for every bean - in which you can register
> > whatever you
> > > want [only that bean] to access.
> > >
> > > Depending on the naming service implementation (LDAP | COSNaming
> > > | whatever), calls to the naming service might span processes;
> > > while those to the ENC will [never] do so. Or in other words,
> > > calls to the ENC are always intra-process calls, while the same
> > > [cannot] be guaranteed with the naming service given that it is
> > > AppServer vendor specific.
> > >
> > > Since the naming service implementation is vendor specific and
> > > potentially could be either Centralized/Distributed/Homogeneous
> > > across AppServer processes, you cannot register process specific
> > > (or local) resources here. And to make matters complicated
> > > (depending on your view of course), many AppServer vendors offer
> > > your own option (Central/ Distributed/Homogeneous) while setting
> > > up the naming service (at least we - Borland - do) based on your
> > > needs/preferences.
> > >
> > > Which brings us to the question - if I cannot use the global JNDI
> > > tree, how do I lookup local EJBs? The answer lies in using the
> > > ENC via EJB Local References entries. EJB Local References are
> > > defined in the deployment descriptor part of the caller bean and
> > > point to the local bean that is the target of the lookup. So
> > > assuming you gave the EJB Local References a name such as
> > > "ejb/EmployeeEjb" and pointed to the Employee local EJB, then
> > > the above local bean can be looked up in the ENC of the caller
> > > by appending the "java:comp/env/" prefix to the string. So, now
> > > your code for looking up a local bean would be:
> > >
> > > javax.naming.Context jndiContext =
> > > new javax.naming.InitialContext();
> > > Object localRef = jndiContext.lookup(
> > > "java:comp/env/ejb/EmployeeEjb");
> > >
> > > I wonder if developers actually use the above spec compliant
> > > and portable mechanism of performing a lookup on a local bean?
> > >
> > > I'd be interested in other thoughts on this. Unfortunately, not
> > > many books/articles I've come across explain these concepts in
> > > sufficient detail.
> > >
> > > -krish
> > >
> > >
> > ==============================================================
> > =============
> > > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the
> > > body of the message "signoff EJB-INTEREST". For general help, send
> > > email to [EMAIL PROTECTED] and include in the body of
> > the message
> > > "help".
> >
> >
> >
> >
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
