deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <lightguard...@gmail.com>
Subject Re: Blocking issue in jpa / transaction module
Date Tue, 17 Jul 2012 16:49:07 GMT
Compile time.

On Tue, Jul 17, 2012 at 9:15 AM, Romain Manni-Bucau
<rmannibucau@gmail.com>wrote:

> Compile or runtime/test dep?
>
> Well IMO a helper shouldnt be in the api, in particular this one which is
> only technical.
>
> - Romain
> Le 17 juil. 2012 17:04, "Jason Porter" <lightguard.jp@gmail.com> a écrit :
>
> > Thanks Pete. Another option is to improve the embedded weld container.
> >
> > On Tue, Jul 17, 2012 at 9:01 AM, Pete Muir <pmuir@redhat.com> wrote:
> >
> > > The Weld EE embedded container was never intended to be used "in
> anger".
> > > It's, at best, an approximation of a real container, which can be used
> > for
> > > a quick bit of debugging.
> > >
> > > It's also not a real target for deltapsike, as you wouldn't ever deploy
> > an
> > > app to it. I would suggest just ignoring this test for the container,
> as
> > > long as it passes on real containers like AS, and TomEE
> > >
> > > On 17 Jul 2012, at 15:53, Jason Porter wrote:
> > >
> > > > 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
> > >
> > >
> >
> >
> > --
> > 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
> >
>



-- 
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

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