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.countSomething(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
