Charles Crain wrote:
>
> Yes that is the same problem I ran into with the java: namespace being linked to
> a JNDI context held by each container.
Hi, Marc and I are looking at it right now. You are right. The java:
namespace should not be threadlocal. It is implemented as threadlocal
in the current jnp implementation and we should really fix that.
You're probably right in saying that it should be the context that is
threadlocal. However, most of the container is built on the threadlocal
assumption of jnp. Again we should fix that but we believe it is a
significant effort.
We might have a way (not as elegant as yours..) to provide a solution
for lookup(java:comp/Usertransaction) in the mean time. Basically we
would bind a reference and provide the factory that returns
getUserTransaction from the EnterpriseContext.
It is a stop-gap solution but it should work quite nicely and we can do
it in a couple of minutes. Maybe you can help us put the more elegant
solution you propose in practice.
Sebastien (and Marc)
>
> I can think of a couple of ways to attack this, but I think the most elegant way
> is to extend javaURLConextFactory. Right now, this class implements the
> Container-bound-ness of the java: namespace. However, if I read the spec
> correctly, this behavior only makes sense for the "java:/comp/env" context,
> since this context is local to each bean type. However, "java:/comp" is global,
> accessible from any thread. Therefore, the javaURLContextFactory could delegate
> comp namespaces to a specialized comp context factory object that could serve as
> a registry for things like the UserTransaction. And if we want to serve up the
> UserTransaction to remote clients, we'd need a UserTransaction implementation
> similar to the one within EnterpriseContext, but that extends
> java.rmi.server.UnicastRemoteObject.
>
> The magic, I realize, is in the delegation mentioned above...i.e., when to
> return contexts bound to the Container versus a global Context. I think it's
> clear that the javaURLContextFactory might have to do some name parsing of its
> own and gain some more intelligence.
>
> -Charles
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
