Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of lightguard.jp@gmail.com
 designates 209.85.213.175 as permitted sender)
MIME-Version: 1.0
From: Jason Porter <lightguard.jp@gmail.com>
Date: Tue, 17 Jul 2012 08:53:21 -0600
Message-ID: 
 <CAF9TksOs67pPj25M36jY-JJChVyFGjP5UdCbEE-V8-_ftYDAZg@mail.gmail.com>
Subject: Blocking issue in jpa / transaction module
To: deltaspike-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae934062b6b4db704c507b610

--14dae934062b6b4db704c507b610
Content-Type: text/plain; charset=UTF-8

I discovered yesterday an issue I would call a blocker for the
v0.3-incubating release. In the JPA / Transaction module we have the
interceptor binding in the API jar, the interceptor implementation in the
impl jar. So far everything is good. We have the TransactionHelper class in
the API jar which allows a Runnable to be executed with a transaction, done
via the transaction interceptor. This is where we have the problem. The api
jar now has a dependency on the impl jar if the TransactionHelper class is
to be used. I ran across this problem in the one test that uses this helper
class. Everything is fine inside TomEE and JBoss AS7 which I tested,
however, in the embedded weld container due to multiple definitions of the
interceptor (WEB-INF/beans.xml and META-INF/beans.xml). This happens
because of class loading issues it seems.

I believe we have a few solutions:

1) Move the TransactionHelper class into the impl jar requiring users to
have a compile dependency on the impl jar
2) Move the interceptor implementation to the api jar (we'd have to change
the interceptor definition in the beans.xml) and we have an implementation
in the api jar
3) Create a one off deployment targeting the embedded weld container (and
others if the same problem is found)

I know doing little one offs isn't the way we always want to handle things,
but this certainly seems like the simplest road ahead right now. Thoughts?

-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu

--14dae934062b6b4db704c507b610--