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 <[email protected]>: > 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 <[email protected]> > wrote: > > > hi david, > > > > i've created DELTASPIKE-986 for it. > > > > regards, > > gerhard > > > > > > > > 2015-09-03 10:30 GMT+02:00 Gerhard Petracek <[email protected]>: > > > > > 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 <[email protected]>: > > > > > >> 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 > > >> > > > > > > > > >
