Thank you very much, especially for the super quick replies.

Have a nice day. 😊

Von: Romain Manni-Bucau <[email protected]>
Gesendet: Mittwoch, 4. Dezember 2019 15:15
An: [email protected]
Betreff: Re: OWB Unwrapping of root cause for PostConstruct exceptions

(cause my last mail was unclear - and GMail is not *** working today) It is 
fixed on master ;)

Romain Manni-Bucau
@rmannibucau<https://twitter.com/rmannibucau> |  
Blog<https://rmannibucau.metawerx.net/> | Old 
Blog<http://rmannibucau.wordpress.com> | Github<https://github.com/rmannibucau> 
| LinkedIn<https://www.linkedin.com/in/rmannibucau> | 
Book<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 4 déc. 2019 à 14:42, Barjenbruch, Kjel 
<[email protected]<mailto:[email protected]>> a Ă©crit :
No run-method should be unwrapped.
The idea of the example is:

  *   MainRunnable injects RepositoryUsingClass
  *   MainRunnable#run accesses RepositoryUsingClass#get, catches 
RuntimeExceptions and logs them
  *   RepositoryUsingClass injects ThrowingRepository
  *   RepositoryUsingClass#get reaches through to ThrowingRepository#get
  *   ThrowingRepository throws a RuntimeException in the @PostConstruct via 
#getFancyObject which is given a NullPointerException as cause
  *   ThrowingRepository#get should cause the Exception of the @PostConstruct 
to be thrown

I would expect the RuntimeException to be logged in the MainRunnable. Instead 
the NullPointerException (cause oft he RuntimeException) is logged. This is due 
to OWB unwrapping the causes and throwing the root cause (last cause in the 
cause „list“) instead of the exception which was orginally caught by OWB.

Is this really intended?

I would attach the example as maven project but I’m assuming your mail server 
would not allow that.

Von: Romain Manni-Bucau <[email protected]<mailto:[email protected]>>
Gesendet: Mittwoch, 4. Dezember 2019 14:17
An: [email protected]<mailto:[email protected]>
Betreff: Re: OWB Unwrapping of root cause for PostConstruct exceptions

Don't think so, your case is due to 2 wrappings: one for the run() method and 
one for the postconstruct and both unwrap once it seems

opened https://issues.apache.org/jira/browse/OWB-1303

Romain Manni-Bucau
@rmannibucau<https://twitter.com/rmannibucau> |  
Blog<https://rmannibucau.metawerx.net/> | Old 
Blog<http://rmannibucau.wordpress.com> | Github<https://github.com/rmannibucau> 
| LinkedIn<https://www.linkedin.com/in/rmannibucau> | 
Book<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 4 déc. 2019 à 12:41, Barjenbruch, Kjel 
<[email protected]<mailto:[email protected]>> a Ă©crit :
Hi,

I do understand that rational. But why is the user code exception also 
unwrapped?

The provided stacktrace is one of the following scenario:
We do have a class BatchItemLayoutRepository which accesses an 
LayoutRepository#getLayout(Path) method. That method accesses a map which is 
filled in the post construct. In case a layout file cannot be read a 
NullPointerException is thrown which we wrap in our own exception an 
RuntimeErrorCodeException. The access of  the method returns the 
NullPointerException instead oft he wrapping exception, which is an issue for 
us since the wrapping exception holds the actual useful information about what 
exactly happened (which is now lost). I would expect  OWB to only unwrap its 
own exceptions but not the user code exceptions.
The provided code example displays this exact issue. One would expect that the 
Exception caught and logged in MainRunnable would be the wrapping 
RuntimeException which is thrown in the PostConstruct of the 
ThrowingRepository. But instead the encased NullPointerException is caught and 
logged.

Is this behaviour really intended?

Von: Romain Manni-Bucau <[email protected]<mailto:[email protected]>>
Gesendet: Mittwoch, 4. Dezember 2019 11:26
An: [email protected]<mailto:[email protected]>
Betreff: Re: OWB Unwrapping of root cause for PostConstruct exceptions

Hi,

the rational of such unwrapping is to hide the reflection which does not help 
to understand the cause so we try to only log the user code exception

Hope it makes sense

Romain Manni-Bucau
@rmannibucau<https://twitter.com/rmannibucau> |  
Blog<https://rmannibucau.metawerx.net/> | Old 
Blog<http://rmannibucau.wordpress.com> | Github<https://github.com/rmannibucau> 
| LinkedIn<https://www.linkedin.com/in/rmannibucau> | 
Book<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 4 déc. 2019 à 10:34, Barjenbruch, Kjel 
<[email protected]<mailto:[email protected]>> a Ă©crit :
(One should end an e-mail before sending it.)

Hi again and back to  the question.

We use OWB for our Java SE Applications and ran into an issue: We sometimes do 
throw RuntimeExceptions out of inialization methods annoted with @PostConstruct.
As part of our error handling we do log those exceptions. The issue we are 
facing is that the the exceptions root cause is unwrapped by OWB and thrown 
instead of the original Exception, which causes a loss of information.

My questions are :

  1.  For what reason is the root cause unwrapped?
  2.  Is there a simple workaround for this?

More information is provided below.

Best wishes
Kjel Barjenbruch


The part of code responsible for this is implemented in 
AbstractOwbBean#getRootException method.

The stacktrace oft he unwrapping looks like this (i added a breakpoint in 
#getCause oft he exception to trace this):
Daemon Thread [core-0] (Suspended (breakpoint at line 104 in 
RuntimeErrorCodeException))
        RuntimeErrorCodeException.getCause() line: 104
        ManagedBean<T>(AbstractOwbBean<T>).getRootException(Throwable) line: 151
        ManagedBean<T>(AbstractOwbBean<T>).create(CreationalContext<T>) line: 
137
        ManagedBean<T>.create(CreationalContext<T>) line: 67
        BeanInstanceBag<T>.create(Contextual<T>) line: 76
        CoreContext(AbstractContext).getInstance(Contextual<T>, 
CreationalContext<T>) line: 159
        CoreContext(AbstractContext).get(Contextual<T>, CreationalContext<T>) 
line: 125
        NormalScopedBeanInterceptorHandler.getContextualInstance() line: 101
        NormalScopedBeanInterceptorHandler.get() line: 71
        LayoutRepository$$OwbNormalScopeProxy0.getLayout(Path) line: not 
available
        BatchItemLayoutRepository.init() line: 30
        ... (shortened for readability)

A simple Example would consist oft he following classe:

-- Class using the repository which throws an exception in it’s post construct: 
--
import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;

@ApplicationScoped
public class ClassUsingThrowingRepository {

    @Inject
    ThrowingRepository repo;

    public Object get() {
        return repo.get();
    }

}

-- Repository implementation which throws the exception:
import javax.annotation.PostConstruct;
import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class ThrowingRepository {

    private Object fancyObjectWhichNeverSeesTheLightOfDay;

    @PostConstruct
    void init() {
        fancyObjectWhichNeverSeesTheLightOfDay = getFancyObject();
    }

    private Object getFancyObject() {
        throw new RuntimeException(
                "Wrapping cause.",
                new NullPointerException("Null pointer exception in 
initilization of throwing repo."));
    }

    public Object get() {
        return fancyObjectWhichNeverSeesTheLightOfDay;
    }

}
-- Runnable which accesses the get method:
import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;

@ApplicationScoped
public class MainRunnable implements Runnable {

    @Inject
    RepositoryUsingClass repoUsingClass;

    @Override
    public void run() {
        try {
            repoUsingClass.get();
        } catch (final RuntimeException exc) {
            LOGGER.error("Caught exception.", exc);
        }
    }

}

Von: Barjenbruch, Kjel
Gesendet: Mittwoch, 4. Dezember 2019 10:17
An: '[email protected]<mailto:[email protected]>' 
<[email protected]<mailto:[email protected]>>
Betreff: OWB Unwrapping of root cause for PostConstruct exceptions

Hello,
We use OWB for our Java SE Applications and ran into an issue: We sometimes do 
throw RuntimeExceptions out of inialization methods



CEWE Stiftung & Co. KGaA mit Sitz in Oldenburg; Registergericht Oldenburg HR B 
208214; Persönlich haftende geschĂ€ftsfĂŒhrende und vertretungsberechtigte 
Gesellschafterin:
NeumĂŒller CEWE COLOR Stiftung, Sitz: Oldenburg;
Stiftungsverzeichnis der rechtsfĂ€higen Stiftungen des bĂŒrgerlichen Rechts im 
Bezirk der Regierungsvertretung Oldenburg Nummer 15(034).
Stiftungsvorstand:
Dr. Christian Friege (Vorsitzender), Patrick Berkhouwer, Dr. Reiner Fageth, 
Carsten Heitkamp, Dr. Olaf HolzkÀmper, Thomas Mehls, Frank Zweigle
Aufsichtsrat:
Otto Korte (Vorsitzender)
UST ID-Nr. DE815453806; St.-Nr. 64/200/38999; GLN 40 04468 00000 4


CEWE Stiftung & Co. KGaA mit Sitz in Oldenburg; Registergericht Oldenburg HR B 
208214; Persönlich haftende geschĂ€ftsfĂŒhrende und vertretungsberechtigte 
Gesellschafterin:
NeumĂŒller CEWE COLOR Stiftung, Sitz: Oldenburg;
Stiftungsverzeichnis der rechtsfĂ€higen Stiftungen des bĂŒrgerlichen Rechts im 
Bezirk der Regierungsvertretung Oldenburg Nummer 15(034).
Stiftungsvorstand:
Dr. Christian Friege (Vorsitzender), Patrick Berkhouwer, Dr. Reiner Fageth, 
Carsten Heitkamp, Dr. Olaf HolzkÀmper, Thomas Mehls, Frank Zweigle
Aufsichtsrat:
Otto Korte (Vorsitzender)
UST ID-Nr. DE815453806; St.-Nr. 64/200/38999; GLN 40 04468 00000 4


CEWE Stiftung & Co. KGaA mit Sitz in Oldenburg; Registergericht Oldenburg HR B 
208214; Persönlich haftende geschĂ€ftsfĂŒhrende und vertretungsberechtigte 
Gesellschafterin:
NeumĂŒller CEWE COLOR Stiftung, Sitz: Oldenburg;
Stiftungsverzeichnis der rechtsfĂ€higen Stiftungen des bĂŒrgerlichen Rechts im 
Bezirk der Regierungsvertretung Oldenburg Nummer 15(034).
Stiftungsvorstand:
Dr. Christian Friege (Vorsitzender), Patrick Berkhouwer, Dr. Reiner Fageth, 
Carsten Heitkamp, Dr. Olaf HolzkÀmper, Thomas Mehls, Frank Zweigle
Aufsichtsrat:
Otto Korte (Vorsitzender)
UST ID-Nr. DE815453806; St.-Nr. 64/200/38999; GLN 40 04468 00000 4


CEWE Stiftung & Co. KGaA mit Sitz in Oldenburg; Registergericht Oldenburg HR B 
208214; Persönlich haftende geschĂ€ftsfĂŒhrende und vertretungsberechtigte 
Gesellschafterin:
NeumĂŒller CEWE COLOR Stiftung, Sitz: Oldenburg;
Stiftungsverzeichnis der rechtsfĂ€higen Stiftungen des bĂŒrgerlichen Rechts im 
Bezirk der Regierungsvertretung Oldenburg Nummer 15(034).
Stiftungsvorstand:
Dr. Christian Friege (Vorsitzender), Patrick Berkhouwer, Dr. Reiner Fageth, 
Carsten Heitkamp, Dr. Olaf HolzkÀmper, Thomas Mehls, Frank Zweigle
Aufsichtsrat:
Otto Korte (Vorsitzender)
UST ID-Nr. DE815453806; St.-Nr. 64/200/38999; GLN 40 04468 00000 4

Reply via email to