Fwd: Question related to GeronimoTransactionManager and JNDI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Question related to GeronimoTransactionManager and JNDI

Jacopo Cappellato-4
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 <[hidden email]>
> Date: September 22, 2009 7:33:59 PM GMT+02:00
> To: [hidden email]
> Subject: Re: Question related to GeronimoTransactionManager and JNDI
> Reply-To: [hidden email]
>
>
> 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
>