Alan,
I had meant to respond to this a couple of weeks ago. Sorry for the delay.
>I'm trying to understand exactly how the java: namespace can be implemented
>...
>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.
The "java namespace" is distinct from any other namespace, such as the
COS Naming namespace. It's cleanest not to think of the leading
"java:" as being part of that namespace. Instead, think of it like a
URL schema that identifies the namespace of what follows. So,
for example, the name "comp/env/ejb/Employee" is a name within the
"java" namespace. The name "java:comp/env/ejb/Employee" is a URL
containing both this name and an indicator of its namespace. As
an analogy, "/var/tmp/foo" is a file name within the filesystem namespace,
while "file:/var/tmp/foo" is a URL containing both the file name and
a namespace indicator.
The default initial context provided to JNDI applications
"understands" URLs. It works by taking the URL's schema (the part
before the colon) and looking for a factory (a "URL context factory"
in JNDI parlance) for resolving those URLs. The Container Provider is
responsible for providing the factory for "java:" URLs. The actual
implementation will probably be a trivial wrapper around the
implementation of the namespace itself. That is, the implementation
of initCtx.lookup("java:x/y/z") will probably just grab a reference to
the root of the "java" namespace, and then call javaRoot.lookup("x/y/z").
The implementation of the "java" namespace can be as simple as a bunch
of nested hash tables, or as complex as needed to provide the desired
persistence, scalability, replication, deployment tools, etc. A COS
Naming server is potentially a reasonable implementation of this
namespace, although I think the Container Provider would need to place
some kind of wrapper around it -- rather than using it directly -- in
order to be able to bind non-CORBA objects such as resource factory
references.
>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.
No, that's not the case. First a detail: the property of interest is
"java.naming.factory.url.pkgs" (rather than "java.naming.factory.initial"),
since that's what controls the location of the "java:" URL context factory.
Each component can share identical initial contexts: it's only once it
drills down into the "java" namespace that the Container must make
distinctions.
A single value for this property, and a single implementation of the
corresponding class, should suffice for the entire Container. Each
EJB can have a value buried by the Container in its thread-local
state. This value would identify the component to the Container,
allowing the Container to provide the necessary customization to the
"java" namespace.
Note that a few months ago there was some discussion about having
multiple "loosely coupled" Containers running with a single JVM. In that
case it becomes a bit more tricky for each Container to supply its
own URL context factory implementation, and we discussed classloader
tricks that -- while a bit ugly -- would accomplish this. But that
discussion was not about the common case, and should be of interest
only to a few Container implementers doing uncommon things.
Scott Seligman
Java Software Engineering
Sun Microsystems
P.S. I'm going to be out of town and incommunicado for the next week.
I'll follow up on any responses when I return.
===========================================================================
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".
