2:34 a.m.
Comments inline.
On Thursday 22 September 2011 10:30 AM, David M. Lloyd wrote:
Client JNDI Revisited!
----------------------
Based on feedback here and in IRC, we're changing our approach to client
EJB thus:
A new JNDI "scheme" will be introduced called "ejb". Lookups into
this
scheme following a naming convention will yield remote EJB proxies
directly. If the interface is not stateful, then the proxy is
immediately available without a server round-trip.
The format for "ejb" scheme names is like this (square brackets are not
literal; they indicate that the enclosed section is optional):
"ejb:appname/modulename/[distinctname/]beanname!interface[?stateful]"
The
appname (assuming it's the .ear name that we talking of, like in the
spec) should be optional too, isn't it? Although making appname optional
might end up with non-deterministic jndi name like:
ejb:a/b/c!interface
and we wouldn't know whether:
1) "a" is appname and "b" is module name
or
2) "a" is module name and "b" is distinctname
The "appname", "modulename", and "distinctname" are the
identifying
names of the EJB deployment. "beanname" is the EJB-spec name of the
EJB. "interface" is the Java type name of the interface being returned.
The "?stateful" query parameter indicates that a session should be
initiated on lookup.
Since it is likely that users will erroneously use "?stateful" on a
stateful home interface (which is itself stateless), the lookup code
will detect whether the interface extends EJBHome before attempting to
initiate session, and if found will instead emit a warning.
What about a case where
the user adds a "?stateful" to a SLSB jndi name
and we end up doing a server trip and realize it's a SLSB. Do we throw
an error or just log a WARN?
This gives us configuration-free JNDI. Also, it gives us a JNDI name
scheme we can use in server-side EJB references as a lookup-name which
can create dependency-free injections of remote EJBs that may not be
present on the current system. And it's also nice in that it doesn't
interfere with "java:" spec lookups at all.
I didn't understand the
dependency-free injection part, but I guess what
you are saying is that having a new ejb: scheme has an additional
advantage too?
Furthermore, I'm not a JNDI expert, so I might be missing some basic
details. But why not treat "java:global" just like we would treat this
new "ejb:" scheme? Is it the namespace "java:" and its traditional
meaning that it's a in-VM namespace? I mean why do we need a new "ejb:"
scheme for remote clients? Furthermore, although the EJB3 spec or other
spec doesn't say anything for/against using the EJB3.1 spec mandated
JNDI name scheme (java:global) from remote JVMs, I think some other app
servers (GlassFish?) do allow these JNDI names to be used from a remote
client. EJB3.1 spec Global JNDI section talks about portable JNDI names,
so I'm not sure whether not supporting java:global from a remote client
is right or wrong.
On a slightly different but related note - I believe we'll be backing
this client JNDI impl on our EJB remote client API which uses
EJBClientContext to select a target when a proxy is invoked. The design
for that mandates that a (correct) EJBClientContext be associated with
the caller thread. So in case of JNDI invocation which would look like:
MyEJB proxy = InitialContext.doLookup("ejb:app/module/bean!intf");
proxy.echo("hello");
Is the client still expected to set the EJBClientContext before the
proxy invocation? If not, how would we associate a EJBClientContext
(with the right set of EJB receivers) for the invocation? Does the
jndi.properties and the properties passed to InitialContext constructor
play any role in deciding the set of EJB receivers that are available in
the EJBClientContext?
-Jaikiran