how to support a jta1.1 tx manager in a j2ee 1.4 container

[David Jencks <da...@yahoo.com>]

To get jpa support in we need a jta1.1 transaction manager.  There  
are two possibilities I can think of:

-- Sun might let us certify under j2ee 1.4 while including the jta1.1  
spec jar.  AFAIK only Geir can find out if this is possible.  If we  
can do this, it's by far the best solution.

-- We can make the tx manager/connector stuff a separate module,  
perhaps a plugin, and make 2 versions of anything that uses it.  IIUC  
the parent-child listing on the system modules page, only openejb has  
a dependency on the tx manager that would be affected by this.  I  
think everything else can be dealt with using a modified  
defaultEnvironement.... but I could be very wrong here, we might need  
more versions of all the j2ee apps we deploy :-((((((  In any case I  
think splitting the tx/connector stuff into a separate module would  
be a good idea.

I'm going to look into the second option.... Geir, can you look into  
the first?

thanks
david jencks

Re: how to support a jta1.1 tx manager in a j2ee 1.4 container

[David Jencks <da...@yahoo.com>]

Let me try to be a little clearer about my question:

will sun supply a version of the j2ee 1.4 tck that passes if we  
include jee5 spec interfaces and j2ee 1.4 compliant implementations?   
Would this apply to all, some, or no jee5 spec interfaces?

A similar situation occurs with the QName class: there are 2  
versions, and you can set the tck to expect either one.

I believe the answer to your question below is in the jpa spec -- you  
don't get container managed transactions or jta tx support.

thanks
david jencks


On Sep 10, 2006, at 7:58 PM, Geir Magnusson Jr wrote:

>
>
> David Jencks wrote:
>> To get jpa support in we need a jta1.1 transaction manager.  There  
>> are
>> two possibilities I can think of:
>>
>> -- Sun might let us certify under j2ee 1.4 while including the jta1.1
>> spec jar.  AFAIK only Geir can find out if this is possible.  If  
>> we can
>> do this, it's by far the best solution.
>
> To get JPA support in.... what?  Geronimo as a 1.4 J2EE server?
>
> I wonder how Sun thinks this is going to happen in general - how apps
> outside of a container that use JPA will get tx mgmt... :)  I'll  
> find out.
>
>>
>> -- We can make the tx manager/connector stuff a separate module,  
>> perhaps
>> a plugin, and make 2 versions of anything that uses it.  IIUC the
>> parent-child listing on the system modules page, only openejb has a
>> dependency on the tx manager that would be affected by this.  I think
>> everything else can be dealt with using a modified
>> defaultEnvironement.... but I could be very wrong here, we might need
>> more versions of all the j2ee apps we deploy :-((((((  In any case I
>> think splitting the tx/connector stuff into a separate module  
>> would be a
>> good idea.
>>
>> I'm going to look into the second option.... Geir, can you look  
>> into the
>> first?
>>
>> thanks
>> david jencks
>>
>>
>>

Re: how to support a jta1.1 tx manager in a j2ee 1.4 container

[Geir Magnusson Jr <ge...@apache.org>]

David Jencks wrote:
> To get jpa support in we need a jta1.1 transaction manager.  There are
> two possibilities I can think of:
> 
> -- Sun might let us certify under j2ee 1.4 while including the jta1.1
> spec jar.  AFAIK only Geir can find out if this is possible.  If we can
> do this, it's by far the best solution.

To get JPA support in.... what?  Geronimo as a 1.4 J2EE server?

I wonder how Sun thinks this is going to happen in general - how apps
outside of a container that use JPA will get tx mgmt... :)  I'll find out.

> 
> -- We can make the tx manager/connector stuff a separate module, perhaps
> a plugin, and make 2 versions of anything that uses it.  IIUC the
> parent-child listing on the system modules page, only openejb has a
> dependency on the tx manager that would be affected by this.  I think
> everything else can be dealt with using a modified
> defaultEnvironement.... but I could be very wrong here, we might need
> more versions of all the j2ee apps we deploy :-((((((  In any case I
> think splitting the tx/connector stuff into a separate module would be a
> good idea.
> 
> I'm going to look into the second option.... Geir, can you look into the
> first?
> 
> thanks
> david jencks
> 
> 
>