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:[EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 2:43 PM
To: [email protected]
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.
