You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by David Smalley <sm...@gmail.com> on 2015/09/02 23:54:30 UTC

UserTransactionResolver in Tomcat

Hello,

I am using the Deltaspike JPA module + WELD in a web app targeting Tomcat
(8). I have set up Atomikos Transaction Essentials to provide JTA
transactions, and all of that is working fine. I want to use Deltaspike for
the @Transactional and @TransactionScoped annotations. After enabling the
BeanManagedTransactionStrategy, I received NameNotFound exceptions for
TransactionSynchronizationRegistry. Some quick research showed that
Atomikos implements JTA 1.0 which doesn't include the registry, and
initially I thought this was the problem, but actually, it isn't.

UserTransactionResolver declares a field @Resource UserTransaction
userTransaction. The code seems to assume the only thing which can go wrong
with this is that injection fails and it might be null, but actually, in
Tomcat, it throws a NameNotFound JNDI exception when it is dynamically
instantiated in resolveUserTransaction(), and so its alternative lookup
logic is never called. resolveUserTransaction() catches this exception and
always returns null, which is interpreted as there being an active CMT,
which causes the lookup for the none-existent registry, but that is already
wrong...there is no EJB and thus no CMT in a plain Tomcat environment.

I have been able to make this work by changing the code in one of two ways:
either change the annotation to @Resource(mappedName =
"java:comp/UserTransaction") which causes the injection to succeed, or
remove it entirely, in which case the field is null, and the alternative
lookup logic is (successfully) invoked.

After either of these changes, the BeanManagedUserTransactionStrategy works
correctly, and I have declarative JTA transactions with plain Tomcat +
Atomikos + Eclipselink. However, I don't want to build my own version of
Deltaspike for deployment.

I have worked around this problem by providing my own transaction strategy
which extends BeanManagedUserTransactionStrategy and overrides
resolveUserTransaction() like this:

public UserTransaction resolveUserTransaction() {

    UserTransaction userTransaction = super().resolveUserTransaction();

    if (userTransaction == null) {
        userTransaction = JNDIUtils.lookup("java:comp/UserTransaction",
UserTransaction.class);
    }

    return userTransaction;
}

It works, but it feels like a kludge. For what it is worth, the spec
recommends against assigning to injected fields, probably because you
usually get a proxy rather than a plain object. I think the use of
@Resource in UserTransactionResolver is dangerous, since it can throw an
exception during instantiation, which means handling the failure must
happen in the calling code. Because it is dynamically created in
resolveUserTransaction(), this is possible, but if you had injected it
directly into the strategy there would be no workaround other than copying,
modifying, and renaming the source.

BTW, when I first found this, I tried to find a way to coerce the plain
@Resource annotation into working, either by mapping in web.xml, or trying
to provide my own implementation of WELD's ResourceInjectionServices spi,
but so far, I haven't been able to make it work. WELD's documentation on
replacing that spi seems to be incorrect, though that's not your problem.

I suppose my question is: is there some way in Deltaspike to cause the
@Resource annotation to have the mappedName attribute dynamically added? I
have already determined that the ProcessInjectionPoint event is never fired
for @Resource fields (I tried to handle them in an extension); they are
deferred to the WELD service, which I have been unable to customize.

Dave

Re: UserTransactionResolver in Tomcat

Posted by Gerhard Petracek <ge...@gmail.com>.
hi david,

great to hear that & thx for reporting it!

regards,
gerhard

http://www.irian.at

Your JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache
MyFaces, DeltaSpike and OpenWebBeans



2015-09-03 19:32 GMT+02:00 David Smalley <sm...@gmail.com>:

> Hi Gerhard,
>
> Looks good. All my unit tests pass, and the app works as expected.
>
> Thanks again.
>
> Dave
>
>
> On Thu, Sep 3, 2015 at 10:10 AM, David Smalley <sm...@gmail.com>
> wrote:
>
> > Hi Gerhard,
> >
> > As usual you are a few minutes ahead of me. I just updated
> > deltaspike.version in my POM to 1.5.1-SNAPSHOT and saw the new code in
> > there. I will rip out my custom strategy and test within an hour or so.
> > Thanks for doing it so fast.
> >
> > Dave
> >
> >
> > On Thu, Sep 3, 2015 at 9:47 AM, Gerhard Petracek <
> > gerhard.petracek@gmail.com> wrote:
> >
> >> hi david,
> >>
> >> i just pushed the new approach.
> >> -> it would be great if you can test it (currently we don't have a
> >> test-profile with such a setup).
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2015-09-03 18:42 GMT+02:00 David Smalley <sm...@gmail.com>:
> >>
> >> > Hi Gerhard,
> >> >
> >> > I was literally creating an issue when this email came in. Sorry I
> >> didn't
> >> > save you the trouble, but thanks for your quick response.
> >> >
> >> > Dave
> >> >
> >> >
> >> > On Thu, Sep 3, 2015 at 8:50 AM, Gerhard Petracek <
> gpetracek@apache.org>
> >> > wrote:
> >> >
> >> > > hi david,
> >> > >
> >> > > i've created DELTASPIKE-986 for it.
> >> > >
> >> > > regards,
> >> > > gerhard
> >> > >
> >> > >
> >> > >
> >> > > 2015-09-03 10:30 GMT+02:00 Gerhard Petracek <gp...@apache.org>:
> >> > >
> >> > > > hi david,
> >> > > >
> >> > > > please create a jira-ticket for such an improvement and i'll fix
> it
> >> > soon.
> >> > > >
> >> > > > regards,
> >> > > > gerhard
> >> > > >
> >> > > >
> >> > > >
> >> > > > 2015-09-02 23:54 GMT+02:00 David Smalley <
> smalley.thedave@gmail.com
> >> >:
> >> > > >
> >> > > >> Hello,
> >> > > >>
> >> > > >> I am using the Deltaspike JPA module + WELD in a web app
> targeting
> >> > > Tomcat
> >> > > >> (8). I have set up Atomikos Transaction Essentials to provide JTA
> >> > > >> transactions, and all of that is working fine. I want to use
> >> > Deltaspike
> >> > > >> for
> >> > > >> the @Transactional and @TransactionScoped annotations. After
> >> enabling
> >> > > the
> >> > > >> BeanManagedTransactionStrategy, I received NameNotFound
> exceptions
> >> for
> >> > > >> TransactionSynchronizationRegistry. Some quick research showed
> that
> >> > > >> Atomikos implements JTA 1.0 which doesn't include the registry,
> and
> >> > > >> initially I thought this was the problem, but actually, it isn't.
> >> > > >>
> >> > > >> UserTransactionResolver declares a field @Resource
> UserTransaction
> >> > > >> userTransaction. The code seems to assume the only thing which
> can
> >> go
> >> > > >> wrong
> >> > > >> with this is that injection fails and it might be null, but
> >> actually,
> >> > in
> >> > > >> Tomcat, it throws a NameNotFound JNDI exception when it is
> >> dynamically
> >> > > >> instantiated in resolveUserTransaction(), and so its alternative
> >> > lookup
> >> > > >> logic is never called. resolveUserTransaction() catches this
> >> exception
> >> > > and
> >> > > >> always returns null, which is interpreted as there being an
> active
> >> > CMT,
> >> > > >> which causes the lookup for the none-existent registry, but that
> is
> >> > > >> already
> >> > > >> wrong...there is no EJB and thus no CMT in a plain Tomcat
> >> environment.
> >> > > >>
> >> > > >> I have been able to make this work by changing the code in one of
> >> two
> >> > > >> ways:
> >> > > >> either change the annotation to @Resource(mappedName =
> >> > > >> "java:comp/UserTransaction") which causes the injection to
> >> succeed, or
> >> > > >> remove it entirely, in which case the field is null, and the
> >> > alternative
> >> > > >> lookup logic is (successfully) invoked.
> >> > > >>
> >> > > >> After either of these changes, the
> >> BeanManagedUserTransactionStrategy
> >> > > >> works
> >> > > >> correctly, and I have declarative JTA transactions with plain
> >> Tomcat +
> >> > > >> Atomikos + Eclipselink. However, I don't want to build my own
> >> version
> >> > of
> >> > > >> Deltaspike for deployment.
> >> > > >>
> >> > > >> I have worked around this problem by providing my own transaction
> >> > > strategy
> >> > > >> which extends BeanManagedUserTransactionStrategy and overrides
> >> > > >> resolveUserTransaction() like this:
> >> > > >>
> >> > > >> public UserTransaction resolveUserTransaction() {
> >> > > >>
> >> > > >>     UserTransaction userTransaction =
> >> > super().resolveUserTransaction();
> >> > > >>
> >> > > >>     if (userTransaction == null) {
> >> > > >>         userTransaction =
> >> > JNDIUtils.lookup("java:comp/UserTransaction",
> >> > > >> UserTransaction.class);
> >> > > >>     }
> >> > > >>
> >> > > >>     return userTransaction;
> >> > > >> }
> >> > > >>
> >> > > >> It works, but it feels like a kludge. For what it is worth, the
> >> spec
> >> > > >> recommends against assigning to injected fields, probably because
> >> you
> >> > > >> usually get a proxy rather than a plain object. I think the use
> of
> >> > > >> @Resource in UserTransactionResolver is dangerous, since it can
> >> throw
> >> > an
> >> > > >> exception during instantiation, which means handling the failure
> >> must
> >> > > >> happen in the calling code. Because it is dynamically created in
> >> > > >> resolveUserTransaction(), this is possible, but if you had
> >> injected it
> >> > > >> directly into the strategy there would be no workaround other
> than
> >> > > >> copying,
> >> > > >> modifying, and renaming the source.
> >> > > >>
> >> > > >> BTW, when I first found this, I tried to find a way to coerce the
> >> > plain
> >> > > >> @Resource annotation into working, either by mapping in web.xml,
> or
> >> > > trying
> >> > > >> to provide my own implementation of WELD's
> >> ResourceInjectionServices
> >> > > spi,
> >> > > >> but so far, I haven't been able to make it work. WELD's
> >> documentation
> >> > on
> >> > > >> replacing that spi seems to be incorrect, though that's not your
> >> > > problem.
> >> > > >>
> >> > > >> I suppose my question is: is there some way in Deltaspike to
> cause
> >> the
> >> > > >> @Resource annotation to have the mappedName attribute dynamically
> >> > > added? I
> >> > > >> have already determined that the ProcessInjectionPoint event is
> >> never
> >> > > >> fired
> >> > > >> for @Resource fields (I tried to handle them in an extension);
> they
> >> > are
> >> > > >> deferred to the WELD service, which I have been unable to
> >> customize.
> >> > > >>
> >> > > >> Dave
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Re: UserTransactionResolver in Tomcat

Posted by David Smalley <sm...@gmail.com>.
Hi Gerhard,

Looks good. All my unit tests pass, and the app works as expected.

Thanks again.

Dave


On Thu, Sep 3, 2015 at 10:10 AM, David Smalley <sm...@gmail.com>
wrote:

> Hi Gerhard,
>
> As usual you are a few minutes ahead of me. I just updated
> deltaspike.version in my POM to 1.5.1-SNAPSHOT and saw the new code in
> there. I will rip out my custom strategy and test within an hour or so.
> Thanks for doing it so fast.
>
> Dave
>
>
> On Thu, Sep 3, 2015 at 9:47 AM, Gerhard Petracek <
> gerhard.petracek@gmail.com> wrote:
>
>> hi david,
>>
>> i just pushed the new approach.
>> -> it would be great if you can test it (currently we don't have a
>> test-profile with such a setup).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2015-09-03 18:42 GMT+02:00 David Smalley <sm...@gmail.com>:
>>
>> > Hi Gerhard,
>> >
>> > I was literally creating an issue when this email came in. Sorry I
>> didn't
>> > save you the trouble, but thanks for your quick response.
>> >
>> > Dave
>> >
>> >
>> > On Thu, Sep 3, 2015 at 8:50 AM, Gerhard Petracek <gp...@apache.org>
>> > wrote:
>> >
>> > > hi david,
>> > >
>> > > i've created DELTASPIKE-986 for it.
>> > >
>> > > regards,
>> > > gerhard
>> > >
>> > >
>> > >
>> > > 2015-09-03 10:30 GMT+02:00 Gerhard Petracek <gp...@apache.org>:
>> > >
>> > > > hi david,
>> > > >
>> > > > please create a jira-ticket for such an improvement and i'll fix it
>> > soon.
>> > > >
>> > > > regards,
>> > > > gerhard
>> > > >
>> > > >
>> > > >
>> > > > 2015-09-02 23:54 GMT+02:00 David Smalley <smalley.thedave@gmail.com
>> >:
>> > > >
>> > > >> Hello,
>> > > >>
>> > > >> I am using the Deltaspike JPA module + WELD in a web app targeting
>> > > Tomcat
>> > > >> (8). I have set up Atomikos Transaction Essentials to provide JTA
>> > > >> transactions, and all of that is working fine. I want to use
>> > Deltaspike
>> > > >> for
>> > > >> the @Transactional and @TransactionScoped annotations. After
>> enabling
>> > > the
>> > > >> BeanManagedTransactionStrategy, I received NameNotFound exceptions
>> for
>> > > >> TransactionSynchronizationRegistry. Some quick research showed that
>> > > >> Atomikos implements JTA 1.0 which doesn't include the registry, and
>> > > >> initially I thought this was the problem, but actually, it isn't.
>> > > >>
>> > > >> UserTransactionResolver declares a field @Resource UserTransaction
>> > > >> userTransaction. The code seems to assume the only thing which can
>> go
>> > > >> wrong
>> > > >> with this is that injection fails and it might be null, but
>> actually,
>> > in
>> > > >> Tomcat, it throws a NameNotFound JNDI exception when it is
>> dynamically
>> > > >> instantiated in resolveUserTransaction(), and so its alternative
>> > lookup
>> > > >> logic is never called. resolveUserTransaction() catches this
>> exception
>> > > and
>> > > >> always returns null, which is interpreted as there being an active
>> > CMT,
>> > > >> which causes the lookup for the none-existent registry, but that is
>> > > >> already
>> > > >> wrong...there is no EJB and thus no CMT in a plain Tomcat
>> environment.
>> > > >>
>> > > >> I have been able to make this work by changing the code in one of
>> two
>> > > >> ways:
>> > > >> either change the annotation to @Resource(mappedName =
>> > > >> "java:comp/UserTransaction") which causes the injection to
>> succeed, or
>> > > >> remove it entirely, in which case the field is null, and the
>> > alternative
>> > > >> lookup logic is (successfully) invoked.
>> > > >>
>> > > >> After either of these changes, the
>> BeanManagedUserTransactionStrategy
>> > > >> works
>> > > >> correctly, and I have declarative JTA transactions with plain
>> Tomcat +
>> > > >> Atomikos + Eclipselink. However, I don't want to build my own
>> version
>> > of
>> > > >> Deltaspike for deployment.
>> > > >>
>> > > >> I have worked around this problem by providing my own transaction
>> > > strategy
>> > > >> which extends BeanManagedUserTransactionStrategy and overrides
>> > > >> resolveUserTransaction() like this:
>> > > >>
>> > > >> public UserTransaction resolveUserTransaction() {
>> > > >>
>> > > >>     UserTransaction userTransaction =
>> > super().resolveUserTransaction();
>> > > >>
>> > > >>     if (userTransaction == null) {
>> > > >>         userTransaction =
>> > JNDIUtils.lookup("java:comp/UserTransaction",
>> > > >> UserTransaction.class);
>> > > >>     }
>> > > >>
>> > > >>     return userTransaction;
>> > > >> }
>> > > >>
>> > > >> It works, but it feels like a kludge. For what it is worth, the
>> spec
>> > > >> recommends against assigning to injected fields, probably because
>> you
>> > > >> usually get a proxy rather than a plain object. I think the use of
>> > > >> @Resource in UserTransactionResolver is dangerous, since it can
>> throw
>> > an
>> > > >> exception during instantiation, which means handling the failure
>> must
>> > > >> happen in the calling code. Because it is dynamically created in
>> > > >> resolveUserTransaction(), this is possible, but if you had
>> injected it
>> > > >> directly into the strategy there would be no workaround other than
>> > > >> copying,
>> > > >> modifying, and renaming the source.
>> > > >>
>> > > >> BTW, when I first found this, I tried to find a way to coerce the
>> > plain
>> > > >> @Resource annotation into working, either by mapping in web.xml, or
>> > > trying
>> > > >> to provide my own implementation of WELD's
>> ResourceInjectionServices
>> > > spi,
>> > > >> but so far, I haven't been able to make it work. WELD's
>> documentation
>> > on
>> > > >> replacing that spi seems to be incorrect, though that's not your
>> > > problem.
>> > > >>
>> > > >> I suppose my question is: is there some way in Deltaspike to cause
>> the
>> > > >> @Resource annotation to have the mappedName attribute dynamically
>> > > added? I
>> > > >> have already determined that the ProcessInjectionPoint event is
>> never
>> > > >> fired
>> > > >> for @Resource fields (I tried to handle them in an extension); they
>> > are
>> > > >> deferred to the WELD service, which I have been unable to
>> customize.
>> > > >>
>> > > >> Dave
>> > > >>
>> > > >
>> > > >
>> > >
>> >
>>
>
>

Re: UserTransactionResolver in Tomcat

Posted by David Smalley <sm...@gmail.com>.
Hi Gerhard,

As usual you are a few minutes ahead of me. I just updated
deltaspike.version in my POM to 1.5.1-SNAPSHOT and saw the new code in
there. I will rip out my custom strategy and test within an hour or so.
Thanks for doing it so fast.

Dave


On Thu, Sep 3, 2015 at 9:47 AM, Gerhard Petracek <gerhard.petracek@gmail.com
> wrote:

> hi david,
>
> i just pushed the new approach.
> -> it would be great if you can test it (currently we don't have a
> test-profile with such a setup).
>
> regards,
> gerhard
>
>
>
> 2015-09-03 18:42 GMT+02:00 David Smalley <sm...@gmail.com>:
>
> > Hi Gerhard,
> >
> > I was literally creating an issue when this email came in. Sorry I didn't
> > save you the trouble, but thanks for your quick response.
> >
> > Dave
> >
> >
> > On Thu, Sep 3, 2015 at 8:50 AM, Gerhard Petracek <gp...@apache.org>
> > wrote:
> >
> > > hi david,
> > >
> > > i've created DELTASPIKE-986 for it.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2015-09-03 10:30 GMT+02:00 Gerhard Petracek <gp...@apache.org>:
> > >
> > > > hi david,
> > > >
> > > > please create a jira-ticket for such an improvement and i'll fix it
> > soon.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2015-09-02 23:54 GMT+02:00 David Smalley <smalley.thedave@gmail.com
> >:
> > > >
> > > >> Hello,
> > > >>
> > > >> I am using the Deltaspike JPA module + WELD in a web app targeting
> > > Tomcat
> > > >> (8). I have set up Atomikos Transaction Essentials to provide JTA
> > > >> transactions, and all of that is working fine. I want to use
> > Deltaspike
> > > >> for
> > > >> the @Transactional and @TransactionScoped annotations. After
> enabling
> > > the
> > > >> BeanManagedTransactionStrategy, I received NameNotFound exceptions
> for
> > > >> TransactionSynchronizationRegistry. Some quick research showed that
> > > >> Atomikos implements JTA 1.0 which doesn't include the registry, and
> > > >> initially I thought this was the problem, but actually, it isn't.
> > > >>
> > > >> UserTransactionResolver declares a field @Resource UserTransaction
> > > >> userTransaction. The code seems to assume the only thing which can
> go
> > > >> wrong
> > > >> with this is that injection fails and it might be null, but
> actually,
> > in
> > > >> Tomcat, it throws a NameNotFound JNDI exception when it is
> dynamically
> > > >> instantiated in resolveUserTransaction(), and so its alternative
> > lookup
> > > >> logic is never called. resolveUserTransaction() catches this
> exception
> > > and
> > > >> always returns null, which is interpreted as there being an active
> > CMT,
> > > >> which causes the lookup for the none-existent registry, but that is
> > > >> already
> > > >> wrong...there is no EJB and thus no CMT in a plain Tomcat
> environment.
> > > >>
> > > >> I have been able to make this work by changing the code in one of
> two
> > > >> ways:
> > > >> either change the annotation to @Resource(mappedName =
> > > >> "java:comp/UserTransaction") which causes the injection to succeed,
> or
> > > >> remove it entirely, in which case the field is null, and the
> > alternative
> > > >> lookup logic is (successfully) invoked.
> > > >>
> > > >> After either of these changes, the
> BeanManagedUserTransactionStrategy
> > > >> works
> > > >> correctly, and I have declarative JTA transactions with plain
> Tomcat +
> > > >> Atomikos + Eclipselink. However, I don't want to build my own
> version
> > of
> > > >> Deltaspike for deployment.
> > > >>
> > > >> I have worked around this problem by providing my own transaction
> > > strategy
> > > >> which extends BeanManagedUserTransactionStrategy and overrides
> > > >> resolveUserTransaction() like this:
> > > >>
> > > >> public UserTransaction resolveUserTransaction() {
> > > >>
> > > >>     UserTransaction userTransaction =
> > super().resolveUserTransaction();
> > > >>
> > > >>     if (userTransaction == null) {
> > > >>         userTransaction =
> > JNDIUtils.lookup("java:comp/UserTransaction",
> > > >> UserTransaction.class);
> > > >>     }
> > > >>
> > > >>     return userTransaction;
> > > >> }
> > > >>
> > > >> It works, but it feels like a kludge. For what it is worth, the spec
> > > >> recommends against assigning to injected fields, probably because
> you
> > > >> usually get a proxy rather than a plain object. I think the use of
> > > >> @Resource in UserTransactionResolver is dangerous, since it can
> throw
> > an
> > > >> exception during instantiation, which means handling the failure
> must
> > > >> happen in the calling code. Because it is dynamically created in
> > > >> resolveUserTransaction(), this is possible, but if you had injected
> it
> > > >> directly into the strategy there would be no workaround other than
> > > >> copying,
> > > >> modifying, and renaming the source.
> > > >>
> > > >> BTW, when I first found this, I tried to find a way to coerce the
> > plain
> > > >> @Resource annotation into working, either by mapping in web.xml, or
> > > trying
> > > >> to provide my own implementation of WELD's ResourceInjectionServices
> > > spi,
> > > >> but so far, I haven't been able to make it work. WELD's
> documentation
> > on
> > > >> replacing that spi seems to be incorrect, though that's not your
> > > problem.
> > > >>
> > > >> I suppose my question is: is there some way in Deltaspike to cause
> the
> > > >> @Resource annotation to have the mappedName attribute dynamically
> > > added? I
> > > >> have already determined that the ProcessInjectionPoint event is
> never
> > > >> fired
> > > >> for @Resource fields (I tried to handle them in an extension); they
> > are
> > > >> deferred to the WELD service, which I have been unable to customize.
> > > >>
> > > >> Dave
> > > >>
> > > >
> > > >
> > >
> >
>

Re: UserTransactionResolver in Tomcat

Posted by Gerhard Petracek <ge...@gmail.com>.
hi david,

i just pushed the new approach.
-> it would be great if you can test it (currently we don't have a
test-profile with such a setup).

regards,
gerhard



2015-09-03 18:42 GMT+02:00 David Smalley <sm...@gmail.com>:

> Hi Gerhard,
>
> I was literally creating an issue when this email came in. Sorry I didn't
> save you the trouble, but thanks for your quick response.
>
> Dave
>
>
> On Thu, Sep 3, 2015 at 8:50 AM, Gerhard Petracek <gp...@apache.org>
> wrote:
>
> > hi david,
> >
> > i've created DELTASPIKE-986 for it.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2015-09-03 10:30 GMT+02:00 Gerhard Petracek <gp...@apache.org>:
> >
> > > hi david,
> > >
> > > please create a jira-ticket for such an improvement and i'll fix it
> soon.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2015-09-02 23:54 GMT+02:00 David Smalley <sm...@gmail.com>:
> > >
> > >> Hello,
> > >>
> > >> I am using the Deltaspike JPA module + WELD in a web app targeting
> > Tomcat
> > >> (8). I have set up Atomikos Transaction Essentials to provide JTA
> > >> transactions, and all of that is working fine. I want to use
> Deltaspike
> > >> for
> > >> the @Transactional and @TransactionScoped annotations. After enabling
> > the
> > >> BeanManagedTransactionStrategy, I received NameNotFound exceptions for
> > >> TransactionSynchronizationRegistry. Some quick research showed that
> > >> Atomikos implements JTA 1.0 which doesn't include the registry, and
> > >> initially I thought this was the problem, but actually, it isn't.
> > >>
> > >> UserTransactionResolver declares a field @Resource UserTransaction
> > >> userTransaction. The code seems to assume the only thing which can go
> > >> wrong
> > >> with this is that injection fails and it might be null, but actually,
> in
> > >> Tomcat, it throws a NameNotFound JNDI exception when it is dynamically
> > >> instantiated in resolveUserTransaction(), and so its alternative
> lookup
> > >> logic is never called. resolveUserTransaction() catches this exception
> > and
> > >> always returns null, which is interpreted as there being an active
> CMT,
> > >> which causes the lookup for the none-existent registry, but that is
> > >> already
> > >> wrong...there is no EJB and thus no CMT in a plain Tomcat environment.
> > >>
> > >> I have been able to make this work by changing the code in one of two
> > >> ways:
> > >> either change the annotation to @Resource(mappedName =
> > >> "java:comp/UserTransaction") which causes the injection to succeed, or
> > >> remove it entirely, in which case the field is null, and the
> alternative
> > >> lookup logic is (successfully) invoked.
> > >>
> > >> After either of these changes, the BeanManagedUserTransactionStrategy
> > >> works
> > >> correctly, and I have declarative JTA transactions with plain Tomcat +
> > >> Atomikos + Eclipselink. However, I don't want to build my own version
> of
> > >> Deltaspike for deployment.
> > >>
> > >> I have worked around this problem by providing my own transaction
> > strategy
> > >> which extends BeanManagedUserTransactionStrategy and overrides
> > >> resolveUserTransaction() like this:
> > >>
> > >> public UserTransaction resolveUserTransaction() {
> > >>
> > >>     UserTransaction userTransaction =
> super().resolveUserTransaction();
> > >>
> > >>     if (userTransaction == null) {
> > >>         userTransaction =
> JNDIUtils.lookup("java:comp/UserTransaction",
> > >> UserTransaction.class);
> > >>     }
> > >>
> > >>     return userTransaction;
> > >> }
> > >>
> > >> It works, but it feels like a kludge. For what it is worth, the spec
> > >> recommends against assigning to injected fields, probably because you
> > >> usually get a proxy rather than a plain object. I think the use of
> > >> @Resource in UserTransactionResolver is dangerous, since it can throw
> an
> > >> exception during instantiation, which means handling the failure must
> > >> happen in the calling code. Because it is dynamically created in
> > >> resolveUserTransaction(), this is possible, but if you had injected it
> > >> directly into the strategy there would be no workaround other than
> > >> copying,
> > >> modifying, and renaming the source.
> > >>
> > >> BTW, when I first found this, I tried to find a way to coerce the
> plain
> > >> @Resource annotation into working, either by mapping in web.xml, or
> > trying
> > >> to provide my own implementation of WELD's ResourceInjectionServices
> > spi,
> > >> but so far, I haven't been able to make it work. WELD's documentation
> on
> > >> replacing that spi seems to be incorrect, though that's not your
> > problem.
> > >>
> > >> I suppose my question is: is there some way in Deltaspike to cause the
> > >> @Resource annotation to have the mappedName attribute dynamically
> > added? I
> > >> have already determined that the ProcessInjectionPoint event is never
> > >> fired
> > >> for @Resource fields (I tried to handle them in an extension); they
> are
> > >> deferred to the WELD service, which I have been unable to customize.
> > >>
> > >> Dave
> > >>
> > >
> > >
> >
>

Re: UserTransactionResolver in Tomcat

Posted by David Smalley <sm...@gmail.com>.
Hi Gerhard,

I was literally creating an issue when this email came in. Sorry I didn't
save you the trouble, but thanks for your quick response.

Dave


On Thu, Sep 3, 2015 at 8:50 AM, Gerhard Petracek <gp...@apache.org>
wrote:

> hi david,
>
> i've created DELTASPIKE-986 for it.
>
> regards,
> gerhard
>
>
>
> 2015-09-03 10:30 GMT+02:00 Gerhard Petracek <gp...@apache.org>:
>
> > hi david,
> >
> > please create a jira-ticket for such an improvement and i'll fix it soon.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2015-09-02 23:54 GMT+02:00 David Smalley <sm...@gmail.com>:
> >
> >> Hello,
> >>
> >> I am using the Deltaspike JPA module + WELD in a web app targeting
> Tomcat
> >> (8). I have set up Atomikos Transaction Essentials to provide JTA
> >> transactions, and all of that is working fine. I want to use Deltaspike
> >> for
> >> the @Transactional and @TransactionScoped annotations. After enabling
> the
> >> BeanManagedTransactionStrategy, I received NameNotFound exceptions for
> >> TransactionSynchronizationRegistry. Some quick research showed that
> >> Atomikos implements JTA 1.0 which doesn't include the registry, and
> >> initially I thought this was the problem, but actually, it isn't.
> >>
> >> UserTransactionResolver declares a field @Resource UserTransaction
> >> userTransaction. The code seems to assume the only thing which can go
> >> wrong
> >> with this is that injection fails and it might be null, but actually, in
> >> Tomcat, it throws a NameNotFound JNDI exception when it is dynamically
> >> instantiated in resolveUserTransaction(), and so its alternative lookup
> >> logic is never called. resolveUserTransaction() catches this exception
> and
> >> always returns null, which is interpreted as there being an active CMT,
> >> which causes the lookup for the none-existent registry, but that is
> >> already
> >> wrong...there is no EJB and thus no CMT in a plain Tomcat environment.
> >>
> >> I have been able to make this work by changing the code in one of two
> >> ways:
> >> either change the annotation to @Resource(mappedName =
> >> "java:comp/UserTransaction") which causes the injection to succeed, or
> >> remove it entirely, in which case the field is null, and the alternative
> >> lookup logic is (successfully) invoked.
> >>
> >> After either of these changes, the BeanManagedUserTransactionStrategy
> >> works
> >> correctly, and I have declarative JTA transactions with plain Tomcat +
> >> Atomikos + Eclipselink. However, I don't want to build my own version of
> >> Deltaspike for deployment.
> >>
> >> I have worked around this problem by providing my own transaction
> strategy
> >> which extends BeanManagedUserTransactionStrategy and overrides
> >> resolveUserTransaction() like this:
> >>
> >> public UserTransaction resolveUserTransaction() {
> >>
> >>     UserTransaction userTransaction = super().resolveUserTransaction();
> >>
> >>     if (userTransaction == null) {
> >>         userTransaction = JNDIUtils.lookup("java:comp/UserTransaction",
> >> UserTransaction.class);
> >>     }
> >>
> >>     return userTransaction;
> >> }
> >>
> >> It works, but it feels like a kludge. For what it is worth, the spec
> >> recommends against assigning to injected fields, probably because you
> >> usually get a proxy rather than a plain object. I think the use of
> >> @Resource in UserTransactionResolver is dangerous, since it can throw an
> >> exception during instantiation, which means handling the failure must
> >> happen in the calling code. Because it is dynamically created in
> >> resolveUserTransaction(), this is possible, but if you had injected it
> >> directly into the strategy there would be no workaround other than
> >> copying,
> >> modifying, and renaming the source.
> >>
> >> BTW, when I first found this, I tried to find a way to coerce the plain
> >> @Resource annotation into working, either by mapping in web.xml, or
> trying
> >> to provide my own implementation of WELD's ResourceInjectionServices
> spi,
> >> but so far, I haven't been able to make it work. WELD's documentation on
> >> replacing that spi seems to be incorrect, though that's not your
> problem.
> >>
> >> I suppose my question is: is there some way in Deltaspike to cause the
> >> @Resource annotation to have the mappedName attribute dynamically
> added? I
> >> have already determined that the ProcessInjectionPoint event is never
> >> fired
> >> for @Resource fields (I tried to handle them in an extension); they are
> >> deferred to the WELD service, which I have been unable to customize.
> >>
> >> Dave
> >>
> >
> >
>

Re: UserTransactionResolver in Tomcat

Posted by Gerhard Petracek <gp...@apache.org>.
hi david,

i've created DELTASPIKE-986 for it.

regards,
gerhard



2015-09-03 10:30 GMT+02:00 Gerhard Petracek <gp...@apache.org>:

> hi david,
>
> please create a jira-ticket for such an improvement and i'll fix it soon.
>
> regards,
> gerhard
>
>
>
> 2015-09-02 23:54 GMT+02:00 David Smalley <sm...@gmail.com>:
>
>> Hello,
>>
>> I am using the Deltaspike JPA module + WELD in a web app targeting Tomcat
>> (8). I have set up Atomikos Transaction Essentials to provide JTA
>> transactions, and all of that is working fine. I want to use Deltaspike
>> for
>> the @Transactional and @TransactionScoped annotations. After enabling the
>> BeanManagedTransactionStrategy, I received NameNotFound exceptions for
>> TransactionSynchronizationRegistry. Some quick research showed that
>> Atomikos implements JTA 1.0 which doesn't include the registry, and
>> initially I thought this was the problem, but actually, it isn't.
>>
>> UserTransactionResolver declares a field @Resource UserTransaction
>> userTransaction. The code seems to assume the only thing which can go
>> wrong
>> with this is that injection fails and it might be null, but actually, in
>> Tomcat, it throws a NameNotFound JNDI exception when it is dynamically
>> instantiated in resolveUserTransaction(), and so its alternative lookup
>> logic is never called. resolveUserTransaction() catches this exception and
>> always returns null, which is interpreted as there being an active CMT,
>> which causes the lookup for the none-existent registry, but that is
>> already
>> wrong...there is no EJB and thus no CMT in a plain Tomcat environment.
>>
>> I have been able to make this work by changing the code in one of two
>> ways:
>> either change the annotation to @Resource(mappedName =
>> "java:comp/UserTransaction") which causes the injection to succeed, or
>> remove it entirely, in which case the field is null, and the alternative
>> lookup logic is (successfully) invoked.
>>
>> After either of these changes, the BeanManagedUserTransactionStrategy
>> works
>> correctly, and I have declarative JTA transactions with plain Tomcat +
>> Atomikos + Eclipselink. However, I don't want to build my own version of
>> Deltaspike for deployment.
>>
>> I have worked around this problem by providing my own transaction strategy
>> which extends BeanManagedUserTransactionStrategy and overrides
>> resolveUserTransaction() like this:
>>
>> public UserTransaction resolveUserTransaction() {
>>
>>     UserTransaction userTransaction = super().resolveUserTransaction();
>>
>>     if (userTransaction == null) {
>>         userTransaction = JNDIUtils.lookup("java:comp/UserTransaction",
>> UserTransaction.class);
>>     }
>>
>>     return userTransaction;
>> }
>>
>> It works, but it feels like a kludge. For what it is worth, the spec
>> recommends against assigning to injected fields, probably because you
>> usually get a proxy rather than a plain object. I think the use of
>> @Resource in UserTransactionResolver is dangerous, since it can throw an
>> exception during instantiation, which means handling the failure must
>> happen in the calling code. Because it is dynamically created in
>> resolveUserTransaction(), this is possible, but if you had injected it
>> directly into the strategy there would be no workaround other than
>> copying,
>> modifying, and renaming the source.
>>
>> BTW, when I first found this, I tried to find a way to coerce the plain
>> @Resource annotation into working, either by mapping in web.xml, or trying
>> to provide my own implementation of WELD's ResourceInjectionServices spi,
>> but so far, I haven't been able to make it work. WELD's documentation on
>> replacing that spi seems to be incorrect, though that's not your problem.
>>
>> I suppose my question is: is there some way in Deltaspike to cause the
>> @Resource annotation to have the mappedName attribute dynamically added? I
>> have already determined that the ProcessInjectionPoint event is never
>> fired
>> for @Resource fields (I tried to handle them in an extension); they are
>> deferred to the WELD service, which I have been unable to customize.
>>
>> Dave
>>
>
>

Re: UserTransactionResolver in Tomcat

Posted by Gerhard Petracek <gp...@apache.org>.
hi david,

please create a jira-ticket for such an improvement and i'll fix it soon.

regards,
gerhard



2015-09-02 23:54 GMT+02:00 David Smalley <sm...@gmail.com>:

> Hello,
>
> I am using the Deltaspike JPA module + WELD in a web app targeting Tomcat
> (8). I have set up Atomikos Transaction Essentials to provide JTA
> transactions, and all of that is working fine. I want to use Deltaspike for
> the @Transactional and @TransactionScoped annotations. After enabling the
> BeanManagedTransactionStrategy, I received NameNotFound exceptions for
> TransactionSynchronizationRegistry. Some quick research showed that
> Atomikos implements JTA 1.0 which doesn't include the registry, and
> initially I thought this was the problem, but actually, it isn't.
>
> UserTransactionResolver declares a field @Resource UserTransaction
> userTransaction. The code seems to assume the only thing which can go wrong
> with this is that injection fails and it might be null, but actually, in
> Tomcat, it throws a NameNotFound JNDI exception when it is dynamically
> instantiated in resolveUserTransaction(), and so its alternative lookup
> logic is never called. resolveUserTransaction() catches this exception and
> always returns null, which is interpreted as there being an active CMT,
> which causes the lookup for the none-existent registry, but that is already
> wrong...there is no EJB and thus no CMT in a plain Tomcat environment.
>
> I have been able to make this work by changing the code in one of two ways:
> either change the annotation to @Resource(mappedName =
> "java:comp/UserTransaction") which causes the injection to succeed, or
> remove it entirely, in which case the field is null, and the alternative
> lookup logic is (successfully) invoked.
>
> After either of these changes, the BeanManagedUserTransactionStrategy works
> correctly, and I have declarative JTA transactions with plain Tomcat +
> Atomikos + Eclipselink. However, I don't want to build my own version of
> Deltaspike for deployment.
>
> I have worked around this problem by providing my own transaction strategy
> which extends BeanManagedUserTransactionStrategy and overrides
> resolveUserTransaction() like this:
>
> public UserTransaction resolveUserTransaction() {
>
>     UserTransaction userTransaction = super().resolveUserTransaction();
>
>     if (userTransaction == null) {
>         userTransaction = JNDIUtils.lookup("java:comp/UserTransaction",
> UserTransaction.class);
>     }
>
>     return userTransaction;
> }
>
> It works, but it feels like a kludge. For what it is worth, the spec
> recommends against assigning to injected fields, probably because you
> usually get a proxy rather than a plain object. I think the use of
> @Resource in UserTransactionResolver is dangerous, since it can throw an
> exception during instantiation, which means handling the failure must
> happen in the calling code. Because it is dynamically created in
> resolveUserTransaction(), this is possible, but if you had injected it
> directly into the strategy there would be no workaround other than copying,
> modifying, and renaming the source.
>
> BTW, when I first found this, I tried to find a way to coerce the plain
> @Resource annotation into working, either by mapping in web.xml, or trying
> to provide my own implementation of WELD's ResourceInjectionServices spi,
> but so far, I haven't been able to make it work. WELD's documentation on
> replacing that spi seems to be incorrect, though that's not your problem.
>
> I suppose my question is: is there some way in Deltaspike to cause the
> @Resource annotation to have the mappedName attribute dynamically added? I
> have already determined that the ProcessInjectionPoint event is never fired
> for @Resource fields (I tried to handle them in an extension); they are
> deferred to the WELD service, which I have been unable to customize.
>
> Dave
>