openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: JCA Resource Adapter?
Date Thu, 10 Aug 2006 02:49:37 GMT
This is a great post, thanks for the details.  More below...

(I think this thread is going to go down in history as having the  
most usage of three letter abbreviations starting with J and ending  
with A)

On Aug 9, 2006, at 6:22 PM, Patrick Linskey wrote:
>
> In the EJB3 spec, we defined a contract between the JPA impl and the
> "container" (EJB or otherwise), and we convinced the JTA team to  
> add the
> TransactionSynchronizationRegistry interface. So, JTA + the
> JPA/container contract are the best way to use OpenJPA in a Java EE 5
> environment.
[...]
> For J2EE 1.4 apps, JCA does provide some theoretical utility for  
> hooking
> into an appserver's standard JCA configuration mechanisms, and for
> getting registered in JNDI in a somewhat-standard way.
[...]
>
> I guess that we need to decide what the story should be for deploying
> OpenJPA into a pre-Java EE 5 appserver. If we decide that JCA is that
> way, then maybe the best approach is for BEA to contribute the  
> existing
> JCA wrappers around OpenJPA.


OK.  Here is the world from the Geronimo perspective.  We've also  
noticed these shortcomings and have our own implementation of JTA  
which includes functionality *identical* to the  
TransactionSynchronizationRegistry, it's called our  
TransactionContextManager.  It's essentially a bucket where we can  
put connections and cmp instance state and have it tracked with the  
transaction state.  Our JCA implementation is fundamentally bound  
into this and things like our existing CMP support rely critically on  
it.  I.e. our JCA implementation is bound into our extended JTA  
implementation as is our CMP implementation.  All things coordinate  
through this extended JTA implementation.

I think we have the functionality we need to do support JPA through  
JCA and our extended JTA, we're just one Resource Adapter and  
possibly a few customizations short.

We definitely plan to readapt this functionality into the JEE 5  
TransactionSynchronizationRegistry and so on, but for now that would  
be far harder.  We're still J2EE 1.4 and are very much looking for a  
way to get OpenJPA in and usable now.

I haven't seen the resource adapter code, but it may even be possible  
to cook up a wrapped version that even people using Geronimo 1.1 or  
1.1.1 could use.

-David



> Thoughts?
>
> -Patrick
>
> -- 
> Patrick Linskey
> BEA Systems, Inc.
>
>> -----Original Message-----
>> From: Kevin Sutter [mailto:kwsutter@gmail.com]
>> Sent: Wednesday, August 09, 2006 2:43 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: JCA Resource Adapter?
>>
>> According to Section 3 (J2EE Tutorials, specifically 3.2 J2EE
>> Installation
>> Types), the recommended approach to using OpenJPA in a
>> managed environment
>> is via the JCA rar file:
>>
>> JCA: OpenJPA implements the JCA 1.0 spec, and the
>> openjpa-persistence.rarfile that comes in the
>> jca/persistence directory of the distribution can be
>> installed as any other
>> JCA connection resource. This is the preferred way to
>> integrate OpenJPA into
>> a pre-J2EE 5 environment. It allows for simple installation (usually
>> involving uploading or copying openjpa-persistence.rar into
>> the application
>> server's deployment directory), and guided configuration on
>> many appservers.
>>
>> Is this supposed to be part of the OpenJPA deliverable?  I do
>> not seem to
>> building the .rar file, nor can I find any reference to the
>> jca/persistence
>> directory that is mentioned above.  Should I open a JIRA bug for  
>> this?
>>
>> Thanks,
>> Kevin
>>
> ______________________________________________________________________ 
> _
> Notice:  This email message, together with any attachments, may  
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted   
> and/or
> legally privileged, and is intended solely for the use of the  
> individual
> or entity named in this message. If you are not the intended  
> recipient,
> and have received this message in error, please immediately return  
> this
> by email and then delete it.
>


Mime
View raw message