I wrote that years ago and nobody complained about it, until today.... Adding the @XmlTransient should be a good and quick fix.
The benefit of the custom Exception is that this information is stored along with the exception. This information is always lost when you need it to render the exception, as the stack trace may be completely different and even in a from different thread, which mean you loose the information. So ReflectionUtil.getCurrentStackTrace() works the same, but the information is the one of the calling code, not the one of the exception, and that's useless. If you look at a stack trace in Karaf, it looks like the following: org.apache.karaf.shell.support.MultiException: Error installing bundles: Unable to install bundle foo at org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61) ~[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.karaf.bundle.command.Install.execute(Install.java:113) [12:org.apache.karaf.bundle.core:4.1.0.SNAPSHOT] at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:548) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:474) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:363) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:227) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?] at java.lang.Thread.run(Thread.java:745) [?:?] The information in the brackets, at the end of each line, is actually accurate (bundle id, symbolic name, version). Without the information stored in the Exception, I'm not aware of any way to do that unfortunately. 2016-03-18 18:41 GMT+01:00 Matt Sicker <boa...@gmail.com>: > What's wrong with the class context from > ReflectionUtil.getCurrentStackTrace() that requires a custom implementation > of Exception? > > On 18 March 2016 at 12:11, Guillaume Nodet <gno...@apache.org> wrote: > > > The getClassContext() method is used in pax-logging to render the > exception > > in a nicer way. > > I don't have any problem moving the qualifier to protected or whatever, > but > > we'd need to change the code in pax-logging > > > > > > > > > https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144 > > > > > > > > > https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67 > > > > It should not be a big deal, but the current code expect the method to be > > public unfortunately. > > > > Guillaume > > > > > > 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > > > > > Hi Cristiano, > > > > > > I think you are right, it's probably something existing for a while. > I'm > > > just surprised that you encountered now. > > > > > > Let me check your detailed use case that you sent previously. > > > > > > Regards > > > JB > > > > > > > > > On 03/18/2016 05:14 PM, Cristiano Costantini wrote: > > > > > >> Hello all, > > >> > > >> it is some days I was having troubles using CXF services on ServiceMix > > >> (and > > >> it is some days I spam on the mailing list of ServiceMix, Camel and > CXF > > >> :-D > > >> ) and I've finally come to the source of my issues which are due to > the > > >> "endorsed" java.lang.Exception which is used by Karaf: > > >> > > >> > > >> > > > https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java > > >> > > >> My problem is due to the fact that this class has a public property, > > >> public Class[] getClassContext() { > > >> return classContext; > > >> } > > >> which is seen by JaxB at runtime inside Karaf which cause it to > marshall > > >> the Exception in SOAP services with a wrong XML, an XML which include > > >> <classContext> tags. > > >> > > >> The class in Karaf has not changed since committed by Guillaume Nodet > in > > >> 2010, so this issue with CXF has probably always been there. > > >> > > >> In my opinion, this getter should be private or protected as I guess > it > > is > > >> only used on the nested class method's getThrowableContext (it is a > > >> replacement for the JRE's class, I don't think there are external > > project > > >> using this modification of the Exception class). > > >> > > >> > > >> To confirm my thesis, I've hacked the > > org.apache.karaf.exception-2.4.0.jar > > >> inside the lib/endorsed folder with a class compiled by myself where > > I've > > >> changed the method to > > >> private Class[] getClassContext() { > > >> return classContext; > > >> } > > >> and with this hack, Karaf has continued to work (and my CXF service > now > > >> works properly). > > >> > > >> Do you think there are potential side effects in this fix? > > >> Do you need me to open an issue on Jira to handle the problem? > > >> If it is confirmed that the fix of making this method private, do you > > >> think > > >> it could be included soon on the next Karaf Release? > > >> > > >> Thank you very much to all, > > >> Cristiano > > >> > > >> > > > -- > > > Jean-Baptiste Onofré > > > jbono...@apache.org > > > http://blog.nanthrax.net > > > Talend - http://www.talend.com > > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > ------------------------ > > Red Hat, Open Source Integration > > > > Email: gno...@redhat.com > > Web: http://fusesource.com > > Blog: http://gnodet.blogspot.com/ > > > > > > -- > Matt Sicker <boa...@gmail.com> > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
