deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smalley <smalley.thed...@gmail.com>
Subject Re: UserTransactionResolver in Tomcat
Date Thu, 03 Sep 2015 17:10:04 GMT
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 <smalley.thedave@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 <gpetracek@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
> > > >>
> > > >
> > > >
> > >
> >
>

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