That's kind of a nasty trick just to get pretty stack traces. Is this really necessary?
On Fri, Mar 18, 2016 at 3:05 PM Guillaume Nodet <[email protected]> wrote: > 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 <[email protected]>: > > > 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 <[email protected]> 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é <[email protected]>: > > > > > > > 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é > > > > [email protected] > > > > http://blog.nanthrax.net > > > > Talend - http://www.talend.com > > > > > > > > > > > > > > > > -- > > > ------------------------ > > > Guillaume Nodet > > > ------------------------ > > > Red Hat, Open Source Integration > > > > > > Email: [email protected] > > > Web: http://fusesource.com > > > Blog: http://gnodet.blogspot.com/ > > > > > > > > > > > -- > > Matt Sicker <[email protected]> > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
