This is an interesting response I got from one of the committers of
Geronimo, please have a look at it.
What I was trying to do is to fix the code in GeronimoContainer.java
(see the TODO there): we are not using the class (and probably we
don't need it) and so we are not serving JTA objects thru JNDI because
we are using GeronimoTransactionFactory instead.
But it would be nice to fix the GeronimoContainer... also, according
to the reply I got, it seems that we should not use
GeronimoTransactionManager as TransactionManager AND
UserTransaction... but we are already doing it in
GeronimoTransactionFactory.
Hmmm... I'll have to do more research about all this stuff, it is
still a bit confusing to me.
Cheers,
Jacopo
Begin forwarded message:
From: David Jencks <[email protected]>
Date: September 22, 2009 7:33:59 PM GMT+02:00
To: [email protected]
Subject: Re: Question related to GeronimoTransactionManager and JNDI
Reply-To: [email protected]
On Sep 22, 2009, at 8:11 AM, Jacopo Cappellato wrote:
Hi all,
I am one of the committers of the Apache OFBiz project, and as you
may know we are using Geronimo Tx Manager as the default JTA
implementation.
We have some code that is not working and I am wondering if you may
give us some hints to fix it; the code below attempts to bind the
GeronimoTransactionManager using JNDI:
InitialContext ic = new InitialContext();
ic.rebind("java:comp/UserTransaction", new
GeronimoTransactionManager());
unfortunately the code above throws the following exception:
java.lang.IllegalArgumentException: RegistryContext: object to bind
must be Remote, Reference, or Referenceable
I could rant on and on about how jndi is not a suitable choice for
much of anything, let alone component dependency injection.....
however I'll try to stay more focussed.
1. I really doubt you want to bind a transaction manager to
UserTransaction, since that's a separate interface.
2. java:comp is normally a read-only immutable jndi context only
available for javaee components in a javaee environment. The
environment is responsible for setting it up. So, unless OFBiz is
trying to be a javaee container I would advise using a different
location. I realize that other people might disagree with me on this.
3. Jndi pretends to be a universal cross-vm lookup mechanism.
However, in most cases many of the things, such as a transaction
manager, that you are expected to look up in jndi are firmly rooted
in a particular vm and trying to pull it over to another vm just
doesn't make sense. The ee guys sort of pretend this mismatch
doesn't exist by coming up with the java:comp component environment
which is specific to the ee component you are currently in. To work
this requires a lot of container support so you get the correct
environment for each component. I rather doubt you want to try to
implement this kind of support in OFBiz.
4. To make this work, assuming you don't try to invent javee-lite
with OFBiz components getting their own java:comp immutable context,
you need to either bind a Reference that has some information in it
sufficient to find the TransactionManager you started some other
way (for instance, for a particularly gross example, you could put
it in a static field of some OFBiz class) or use a jndi
implementation such as xbean-naming that lets you bind non-
serialzable non-referencable objects directly into jndi.
hope this helps
david jencks
Thanks,
Jacopo Cappellato
