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 <[email protected]>: > 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 <[email protected]> > 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 < > > [email protected]> 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 <[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 > >> > > >> > >> > > > > >> > > > > >> > > > >> > > >> > > > > >
