@RollbackException: that was the reason for providing the protected throwException method. sometimes it's quite specific what you get and what you expect/prefer. -> you can control the behavior as you need it.
regards, gerhard 2018-03-14 14:43 GMT+01:00 Juri Berlanda <[email protected]>: > Hi guys, > > we are currently trying to upgrade from DeltaSpike 1.7.2 to the 1.8 > releases in preparation of CDI-2.0, but we encountered some problems which > for some we are not sure how to handle. They all seem to arise from data- > and jpa-module. In detail: > > # Breaking changes from 1.7.2 to 1.8.0: > > 1. When executing a CriteriaQuery TypedQuery where QuerySelection is a > count() up to including 1.7.2 the ResultClass (i.e. generic type in > TypedQuery) needed to be something which has a (I guess public) constructor > which takes a single Long. Hence, Long itself could not be used since it > has no such constructor. So one needed to implement a wrapper class which > meets the requirement. This is no longer the case and Long can be used > directly. Not only that: it turns out Long HAS to be used, since using the > wrapper class introduced for DeltaSpike 1.7.2 and below now causes a > ClassCastException, i.e.: > > java.lang.ClassCastException: java.lang.Long cannot be cast to > com.example.CountDTOcom.example.SomeRepository.countSomethin > g(SomeRepository.java:XX) > > Reading through the Changelog for 1.8.0 this is not mentioned - or if it > is not in an obvious way. > > # Breaking changes from 1.8.0 to 1.8.1: > > 1. Where previously an EntityExistsException was thrown, now it is a > RollbackException, which getCause() is a EntityExistsException. This is > also mentioned in https://issues.apache.org/jira/browse/DELTASPIKE-1258. > We are handling EntityExistsException explicitly in some parts of our > system, so this has an impact on our logic. Our currently planned > workaround is to override both "protected void throwException(Exception > exception) throws Exception" and "protected Exception > prepareException(Exception e)" from TransactionStrategy to return > getCause() if exception (or e respectively) is instanceof > PersistenceException. Does that make sense? Is there a better (i.e. less > boilerplated) way to do it? Are there any plans to revert the behavior > introduced in 1.8.1 (1.8.0 is explicitly NOT affected) in some future > releases? > > 2. Since the upgrade to 1.8.1 some of our UnitTests fail, because an > EntityManager with @Default cannot be found. This does not make sense in > our scenario, since we have no EnitityManager with @Default - all of them > carry some Qualifier. Again, this behavior was introduced in 1.8.1 (1.8.0 > is explicitly NOT affected). I'm not sure yet what exactly triggers the > problem, I'm currently trying to recreate the issue on a standalone Maven > project. I'll let you know if I succeed. What I currently suspect is some > scenario, where a let's say "@Transactional(qualifier = A.class)" calls a > "@Transactional(qualifier = B.class)" without EntityManager with Qualifier > A.class ever being created. This triggers line 88 in > "ResourceLocalTransactionStrategy.java", which causes Default to be used > as qualifier for EntityManager - which as mentioned - does not exist in our > System. The issue is currently only appearing in custom (i.e. non > DeltaSpike-data) services, but I am still analyzing it > > # Further information > > The rest of the relevant stack is: > > * OpenJPA 2.4.2 > * OpenWebBeans 2.0.4 > * TestNG with DeltaSpike cdi-ctrl > > Thanks in advance for any information and keep up the great work. > DeltaSpike is awesome and I can't wait to upgrade to 1.8.1, especially for > the new @EntityManagerConfig just requiring a qualifier for the > EntityManager to use. > > Kind regards, > > Juri Berlanda > >
