Yes that is the same problem I ran into with the java: namespace being linked to
a JNDI context held by each container.
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
marc fleury wrote:
> Ok for the JNDI stuff it is going to be a bit more complex than I first
> thought (no wonder it was NYI). The trick is that the JNDI name java: is
> static for the container and instead of doing a copy of it (which would be
> very heavy) we would like to store a ref to the Tx that is linked to the
> context of the instance. We will need a factory that is thread local
> somehow, and right now we need to do it...
>
> so getUserTransaction from the context is the simple way to do it.
>
> marc
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
> > Sent: Thursday, September 14, 2000 5:22 PM
> > To: jBoss
> > Subject: RE: [jBoss-User] UserTrasaction
> >
> >
> > Ok we just looked at it with sebastien.
> >
> > the bottom line is that the Tx from "getUserTransaction" is implemented
> > tx from JNDI is NYI and we are on it, some retooling in order, hang on.
> >
> > marc
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
> > > Sent: Thursday, September 14, 2000 1:13 PM
> > > To: jBoss
> > > Subject: Re: [jBoss-User] UserTrasaction
> > >
> > >
> > > I was looking in the code for this. It appears that looking up a
> > > UserTransation
> > > with JNDI is not supported. The EJB 1.1 spec states explicitly that the
> > > container does not need to make the UserTransaction object
> > > available via JNDI to
> > > ALL clients, though several EJB containers do (JoNaS, WebLogic...)
> > >
> > > What I find weird is that even beans running WITHIN jBoss can't
> > > use JNDI to look
> > > up a UserTransaction object, and then control the transactions of
> > > other beans.
> > > Of couse, you can do the exact same thing by using bean-managed
> > > transactions and
> > > calling the getUserTransaction method of EJBContext.
> > >
> > > What I would like to see is the ability of services running
> > > within jBoss to look
> > > up UserTransaction objects and control transactions of beans.
> > > For instance,
> > > Servlets and JSP's running in the Tomcat service really should be
> > > able to get
> > > access to the UserTransaction object.
> > >
> > > -Charles
> > >
> > > Sean Han wrote:
> > >
> > > > Hi, everyone:
> > > >
> > > > If I want to get a UserTrasaction object from jBoss, what JNDI
> > > name should I
> > > > use in lookup() method?
> > > >
> > > > Thanks!
> > > >
> > > > Sean
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Talk to your friends online with Yahoo! Messenger.
> > > > http://im.yahoo.com
> > > >
> > > > --
> > > > --------------------------------------------------------------
> > > > To subscribe: [EMAIL PROTECTED]
> > > > To unsubscribe: [EMAIL PROTECTED]
> > > > Problems?: [EMAIL PROTECTED]
> > >
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Problems?: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
> >
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
