My memory of the app client code is a little hazy, I seem to recall that there
were some slight differences between the way OpenEJB does app clients and the
way Geronimo does app clients.
The part that I know for sure is that neither uses the names created via the
openejb.jndiname.format. So changing that will (should) have no affect. The
idea is that users should be able to set it to be whatever they want it to be
and that should not break the App Client code. The openejb.jndiname.format is
specifically for "plain" clients and allows them to get the names as they want
them.
Internally, we bind each EJB proxy under essentially a hardcoded and
predictable format and then again using the user supplied format. So there are
at minimum two JNDI trees with every EJB proxy. It used to be two at least.
Now we have quite a few because of Java EE 6 global JNDI and the support we
added for @LocalClient and allowing the same interface to be used as both
@Local and @Remote.
Basically we have:
openejb/Deployment/<hardcoded internal format>
openejb/local/<strategy format>
openejb/remote/<strategy format>
The 'openejb/Deployment' section is the non-changing fully qualified name for
use internally and by app clients.
The 'openejb/remote' section is for "pretty" names looked up via plain clients
using the RemoteInitialContextFactory. The protocol can tell the difference
between app clients and plain clients and knows which area to look in.
The 'openejb/local' section is for "pretty" names looked up via the
LocalInitialContextFactory.
The "pretty" names are defined by the openejb.jndiname.format and since the
user has control of that formatting it's possible that not all proxies can be
bound. Say the bean has both a local and remote interface and the user has
just "{deploymentId}" or "{ejbName}" as the format. Hence those bind calls use
the "optional" set of binding methods.
The format of the internal names bound into openejb/Deployment is guaranteed to
be unique. It's not pretty to look at obviously, but every possible proxy will
be bound there guaranteed. For binding into 'openejb/Deployment' we don't use
the "optional" set of binding methods. If something can't be bound it's a
deployment issue.
In terms of "the home interface is not bound" it is bound, but with the name of
the corresponding business interface rather than the home interface. We can
probably change that to use the home interface name instead. We just want to
be careful to break the OpenEJB app client code in the process. I don't think
there are tests for it. I might be able add one quickly if not.
-David
