This topic was discussed in May and June under the thread: EJB1.1 bean JNDI
question. The questions surround the design and implementation of the java:
namespace (a requirement for J2EE and EJB1.1). A number of questions were
raised including whether the unusual context sensitivity of "java:" was a
good thing or not. Also, there were questions about whether java: is
implementable (in any reasonable way). A few rather vague hints were given
as to how an implementation might proceed.
I'm trying to understand exactly how the java: namespace can be implemented
using a standard namespace provider (such as CosNaming). I'd be interested
in feedback from anyone who has thought about this problem. For the Sun
folks, it would be helpful if someone familiar with these issues could
outline a specific implementation strategy. Here's my take on it. I see 2
main issues. The first is how a JNDI namespace deals with URL names. The
second involves how a particular java: namespace can be chosen on a per bean
basis.
1. The underlying namespace must support URL syntax for names. e.g.
java:comp/... Note we are not talking about InitialContext URL environment
properties here. The namespace must either support URLs as JNDI composite
names, or allow ":" as a legal value within a particular naming component.
Depending on what the underlying namespace/service provider does with the
":" will dictate how the container must implement the context hierarchy.
For example, using CosNaming and the Sun JNDI service provider, "java:comp"
parses as a single atomic name.
2. A unique classloader must be provided for each EJB (not one per whole EJB
app, one per each EJB!!). The classloader will need to load an ejb specific
application resource file named jndi.properties. This file must include a
unique specification for java.naming.factory.initial. The search path for
JNDI properties must be set in such a way that the bean classloader finds
the bean jndi.properties file first. This is tricky because the default
JNDI search path searches the environment and the service provider's
jndiprovider.properties file first (it would be alot easier if it searched
the application resource files first). Both the environment and provider
properties must be circumvented to force the bean JNDI properties to be
used. Removing the jndiprovider.properties file and/or clearing the
environment are not viable options as this impacts other system (non EJB)
services which do not have private jndi.properties.
If 1 and 2 can be satisfied, a per-EJB implementation of InitialContext()
can be established as the Context for finding the appropriate per-EJB java:
entities.
Other issues surround the specific uses of java: For example, can all JNDI
namespaces support the referrals necessary to implement EJB references? Can
CosNaming?
===========================================================================
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".
