>Alan,
>
>I had meant to respond to this a couple of weeks ago. Sorry for the delay.
>
>
Thanks for providing a thoughtful, detailed response.
>
>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").
>
My misunderstaning had to do with the fact the lookup method can take a URL
as well as the constructor for InitialContext. This is apparently a new
feature of JNDI1.2 or at least it is only documented in the 1.2 API.
Since the EJB1.1 spec which outlines the use of java: predated the general
availability of JNDI1.2, it was a bit hard to put together the pieces of the
puzzle. But now I get it.
> ... 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.
>
What mechanisms exist to maintain thread-local state? It seems that the
only available choices are the String thread name or the context
ClassLoader. I don't see subclassing Thread as being an option for adding
state since the container will be called on arbitrary threads controlled by
the exported communication protocol (RMI or RMI-IIOP). So it seems like it
would be necessary for the container to set either the thread name or the
context ClassLoader before delegating method calls into the ejb.
Alan
===========================================================================
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".
