Problems when upgrading to 1.8 Release

[Juri Berlanda <ju...@tuwien.ac.at>]

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

Re: Problems when upgrading to 1.8 Release

[Gerhard Petracek <gp...@apache.org>]

@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 <ju...@tuwien.ac.at>:

> 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
>
>