You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Jason Porter <li...@gmail.com> on 2012/07/17 16:53:21 UTC
Blocking issue in jpa / transaction module
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
Re: Blocking issue in jpa / transaction module
Posted by Jason Porter <li...@gmail.com>.
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 <li...@gmail.com>
>
> > Compile time.
> >
> > On Tue, Jul 17, 2012 at 9:15 AM, Romain Manni-Bucau
> > <rm...@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" <li...@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 <pm...@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
Re: Blocking issue in jpa / transaction module
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <li...@gmail.com>
> Compile time.
>
> On Tue, Jul 17, 2012 at 9:15 AM, Romain Manni-Bucau
> <rm...@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" <li...@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 <pm...@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
>
Re: Blocking issue in jpa / transaction module
Posted by Jason Porter <li...@gmail.com>.
Compile time.
On Tue, Jul 17, 2012 at 9:15 AM, Romain Manni-Bucau
<rm...@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" <li...@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 <pm...@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
Re: Blocking issue in jpa / transaction module
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <li...@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 <pm...@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
>
Re: Blocking issue in jpa / transaction module
Posted by Jason Porter <li...@gmail.com>.
Thanks Pete. Another option is to improve the embedded weld container.
On Tue, Jul 17, 2012 at 9:01 AM, Pete Muir <pm...@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
Re: Blocking issue in jpa / transaction module
Posted by Pete Muir <pm...@redhat.com>.
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