I got annoyed that the global ejb bindings from openejb didn't show up
in the geronimo global jndi tree so thought I'd try to fix it.
My first and possibly ill-advised strategy was to use the same flag we
use to decide what jndi implementation to use for the java:comp
context to decide what to use for the global context. After a little
bit of struggle I think I have this working OK in geronimo.
While doing this I discovered that the openejb jndi implementation
does a couple of odd things:
1. creates subcontexts on the fly when you bind something. I don't
think this is spec compliant but I have no particular objection to it
-- it certainly is handy and I can't see how it can create problems or
confusion.
2. strips off name prefixes such as java: and openejb: I'm not too
sure what the purpose of this is but I think it may be leading to
sloppy and very confusing code in the server. For instance when the
global context is set up we see:
jndiRootContext.createSubcontext("java:openejb/ejb");
jndiRootContext.createSubcontext("java:openejb/client");
jndiRootContext.createSubcontext("java:openejb/
Deployment");
jndiRootContext.bind("openejb/ejb/.", "");
jndiRootContext.bind("openejb/client/.", "");
jndiRootContext.bind("openejb/Deployment/.", "");
I'm not sure the createSubcontext calls are actually necessary due to
(1) but I think it is far from obvious that binding at openejb/ejb/.
occurs in the subcontext just created at java:openejb/ejb.
Similarly pretty much everything is bound into the root context under
"java:" which is stripped off before actually being bound.
At least 90% of the changes I made to get the alternate jndi provider
working were removing the java: from the global names.
I have no objection to the jndi implementation modifying names to make
it easier for users to find stuff -- so for user convenience I think
stripping off java: and other prefixes is just fine. However I think
the server will be a lot less confusing if it does not rely on this
when binding stuff.
So, I'd like to propose that we consider making the jndi provider more
pluggable, and testing everything with a provider that does not strip
off prefixes (such as xbean)
I've created https://issues.apache.org/jira/browse/OPENEJB-1014 and
attached my current patch in case anyone wants to take a look. If
people think going in this direction is a good idea I'd like to see if
there's a cleaner way to supply the jndi contexts, perhaps by
injecting something.
Thoughts?
btw dblevins mentioned that the tomcat integration seemed to be having
some jndi problems. I tried running the tests with my modified
openejb and did not see anything that looked like a jndi problem --
all the tests I could identify as relating to tomcat passed. The
remote tests had this error:
java.lang.IllegalStateException: Cannot find client/tools/
DatabaseHome: javax.naming.NameNotFoundException /client/tools/
DatabaseHome does not exist in the system. Check that the app was
successfully deployed.
which appeared to relate somehow with hsqldb. I didn't investigate
this.
thanks
david jencks
