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 19:10:37 GMT
An idea that just occurred to me is creating an arquillian connector using
our cdictl module? Really all we're trying to do with these embedded
containers is to verify things work correctly in SE, correct? We could
probably better control the classpath as well, yes?

On Tue, Jul 17, 2012 at 1:01 PM, Gerhard Petracek <
gerhard.petracek@gmail.com> wrote:

> imo we need a solution independent of a concrete constellation in
> delaspike.
> due to a similar issue i couldn't commit some tests for the security module
> -> we might see this restriction for other parts as well.
>
> regards,
> gerhard
>
>
>
> 2012/7/17 Jason Porter <lightguard.jp@gmail.com>
>
> > 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
> >
>



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