openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
Subject Re: OPENJPA-149
Date Thu, 17 Apr 2008 13:55:34 GMT
Essentially that's the case. OpenJPA-159 is the JIRA that deals with
creating a doNonTransactionalWork(Runnable r) method on the ManagedRuntime
classes. When that's committed a GeronimoManagedRuntime class could be
written that does whatever needs to be done for Geronimo. Similarly the
existing ManagedRuntimes for WebLogic / SunOne / <insert your favorite app
server here> could be updated to take advantage of the new interface.

OpenJPA-149 is specific to WebSphere and will add a ManagedRuntime that can
handle WebSphere's tweaks. In this case it's not quite as simple as just
calling a methods via reflection.

In order to do the non transactional work in WebSphere we need to provide a
class which implements a proprietary interface. It's rather tricky to do so
when we can't compile against the interface though. We solved a similar
problem for previous releases by using bytecode weaving to add an interface
to a class after we compiled it. The same approach will work, but it's
counter intuitive. We received the appropriate legal clearance from
WebSphere to use their compiled classes, but I wanted to make sure adding
them to SVN was "kosher" before I commit them.


On Wed, Apr 16, 2008 at 8:32 PM, David Jencks <>

> IIUC this is the interface that abstracts the "requiresNew" tx policy into
> a single method on the tm?
> Personally I'd like openjpa to define such an interface and use it no
> matter what the environment.  Then perhaps the websphere adapter code can
> call the WAS interface/class using reflection?
> I've been having big problems with openjpa in geronimo unless I supply
> both the jta and non-jta datasources.  I have some hope that if I can
>  implement such a "doInNewTx" method I'll be able to solve these problems.
> thanks
> david jencks
> On Apr 16, 2008, at 1:03 PM, Michael Dick wrote:
>  I've been looking at this issue and OPENJPA-159 in my "copious" free
> > time.
> > The official supported way to  submit work outside of a transaction in
> > WebSphere is to go through a WebSphere proprietary interface (similar to
> > what we have in WASManagedRuntime).
> >
> > Unfortunately that interface is not published in any maven repository,
> > or
> > generally made available in a central location. We were able to get
> > permission to use a precompiled jar for our build process, but we can't
> > redistribute it (ie publish it to a maven repository). It can be
> > included in
> > our source repository though. I believe this approach is used by other
> > vendors who use the APIs (ie Spring if I'm not mistaken).
> >
> > The net outcome is that we have two options:
> >
> > 1. Use the proprietary interfaces in the same manner as we do in
> > WASManagedRuntime - use serp to add an interface to one of our classes
> > (not
> > an entity) after we've compiled it. When the class is used we'll use
> > reflection to invoke the appropriate methods.
> >
> > 2. Add the WebSphere jar in our svn repository and then reference it as
> > a
> > system dependency (won't be shipped as a dependency) in the maven build
> > .
> > The class(es) that use the proprietary interfaces can call methods
> > directly
> > and we can avoid the bytecode weaving. The downside is there will be a
> > 4.7 K
> > jar file added to svn. It's relatively light weight and it shouldn't be
> > changed often (if at all).
> >
> > How to people feel about including the WebSphere APIs in this way? On
> > the
> > one hand it make the code quite a bit easier to maintain, but on the
> > other
> > hand it's a binary in SVN.
> >
> > -Mike
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message