Re: Problems due to the endorsed java.lang.Exception
Ok, so I've repeated the tests and I confirm that with @XmlTransient annotation the enhanced logging capability is preserved and the CXF error on exceptions is fixed. I've opened a ticket, https://issues.apache.org/jira/browse/KARAF-4429 and I hope it could be fixed before the next releases of Karaf and ServiceMix. To ake the tests, I've cloned karaf git repo and compiled patched version for some different version, I've tested the fix and confirm it work on Karaf 4.0.4, ServiceMix 7.0.0.M1, ServiceMix 6.1.0 and ServiceMix 5.3.0. You can see the console output of the logs for each of the above platforms here: https://gist.github.com/cristcost/4a5c554ccbb9577c690e I have a personal preference for a fix like this: https://github.com/cristcost/karaf/commit/cf1dbaa714f763ce8ee5de9801c4f43fd2fddb22 and we can update pax-log to use the protected method anytime in the future, but I would be happy even if the fix is limited to annotating the method with @XmlTransient. I have not published the test that confirm that CXF is working with this fix, basically I have a simple bundle and I trigger a fault with SOAP request, I've checked manually that with this patch the marshalling is working. If you need more evidence on this test I can provide more support. In the end, if anyone is having these CXF issues and is using a Karaf version which has not been fixed, you can quickly fix the problem by deleting the file org.apache.karaf.exception-X.X.X.jar inside the "lib/endorsed/" folder you'll loose some info on the logs of exception, you can see what you are going to lose between two logs here: https://gist.github.com/cristcost/4a5c554ccbb9577c690e/revisions#diff-73f5d0d8b32831c350a6fcfe04f84659L50 but everything else "should" work properly. Thank you for all the support, plese promote the issue or let me know how I can provide more support, Cristiano Il giorno lun 21 mar 2016 alle ore 10:43 Cristiano Costantini < cristiano.costant...@gmail.com> ha scritto: > Ok, > I've repeated the test WITH the endorsed exception, > > I've updated the previous GIST and from looking at it is now crystal clear > the effects and benefits of endorsing the exception: > > At this link it is shown the differences in the logs: > https://gist.github.com/cristcost/4a5c554ccbb9577c690e/revisions > > I'll now patch the endorsed exception with @XmlTransient and after I'll > confirm that full logging capability is still available > > > > > Il giorno lun 21 mar 2016 alle ore 10:28 Guillaume Nodet < > gno...@apache.org> ha scritto: > >> 2016-03-21 10:06 GMT+01:00 Cristiano Costantini < >> cristiano.costant...@gmail.com>: >> >> > I've tested deleting the endorsed Jar on different clean installations >> of >> > Karaf and ServiceMix, >> > >> > I never get question marks [?:?] on the logs using the log:display >> command, >> > although some line in the printed stack trace does not include bundle >> > information. >> > >> >> Right. The behaviour I pasted earlier was on karaf master branch >> (so with pax logging / log4j v2). The pax logging / log4j v1 does not >> print >> anything when the information is not available. >> >> >> > >> > Here you can check what I've done and what has been logged out >> > https://gist.github.com/cristcost/4a5c554ccbb9577c690e >> > >> > >> > I'm going to repeat the tests with the endorsed Exception for comparing >> the >> > logs. >> > >> > Cristiano >> > >> > >> > Il giorno lun 21 mar 2016 alle ore 09:42 Cristiano Costantini < >> > cristiano.costant...@gmail.com> ha scritto: >> > >> > > >> > > >> > > now it is getting very weird... >> > > intrigued by the test with the protected method I have made another >> test: >> > > I have fully deleted the org.apache.karaf.exception-2.4.0.jar file >> from >> > the >> > > endorsed folder. >> > > And surprisingly, I still get the same logs information with the >> > > log:display command ! >> > > >> > > Please note that I am making this series of tests on ServiceMix 5.3.0, >> > > which is based on Karaf 2.4.0. >> > > This is the output of the test you have suggested: >> > > >> > > karaf@root> log:clear >> > > karaf@root> install foo >> > > Bundle IDs: >> > > Error executing command: Error installing bundles: >> > > Unable to install bundle foo >> > > karaf@root> log:display >> > > 2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console >> > >| ? ? | 20 - >> > > org.apache.karaf.shell.console - 2.4.0 | Exception caught while >> executing >> > > command >> > > org.apache.karaf.shell.console.MultiException: Error installing >> bundles: >> > > Unable to install bundle foo >> > > at >> > > >> > >> org.apache.karaf.shell.console.MultiException.throwIf(MultiException.java:91) >> > > at >> > > >> > >> org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:70) >> > > at >> > > >> > >> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[20:org.apache.karaf.shell.console:2.4.0] >> > > at >
Re: Problems due to the endorsed java.lang.Exception
Ok, I've repeated the test WITH the endorsed exception, I've updated the previous GIST and from looking at it is now crystal clear the effects and benefits of endorsing the exception: At this link it is shown the differences in the logs: https://gist.github.com/cristcost/4a5c554ccbb9577c690e/revisions I'll now patch the endorsed exception with @XmlTransient and after I'll confirm that full logging capability is still available Il giorno lun 21 mar 2016 alle ore 10:28 Guillaume Nodet ha scritto: > 2016-03-21 10:06 GMT+01:00 Cristiano Costantini < > cristiano.costant...@gmail.com>: > > > I've tested deleting the endorsed Jar on different clean installations of > > Karaf and ServiceMix, > > > > I never get question marks [?:?] on the logs using the log:display > command, > > although some line in the printed stack trace does not include bundle > > information. > > > > Right. The behaviour I pasted earlier was on karaf master branch > (so with pax logging / log4j v2). The pax logging / log4j v1 does not > print > anything when the information is not available. > > > > > > Here you can check what I've done and what has been logged out > > https://gist.github.com/cristcost/4a5c554ccbb9577c690e > > > > > > I'm going to repeat the tests with the endorsed Exception for comparing > the > > logs. > > > > Cristiano > > > > > > Il giorno lun 21 mar 2016 alle ore 09:42 Cristiano Costantini < > > cristiano.costant...@gmail.com> ha scritto: > > > > > > > > > > > now it is getting very weird... > > > intrigued by the test with the protected method I have made another > test: > > > I have fully deleted the org.apache.karaf.exception-2.4.0.jar file from > > the > > > endorsed folder. > > > And surprisingly, I still get the same logs information with the > > > log:display command ! > > > > > > Please note that I am making this series of tests on ServiceMix 5.3.0, > > > which is based on Karaf 2.4.0. > > > This is the output of the test you have suggested: > > > > > > karaf@root> log:clear > > > karaf@root> install foo > > > Bundle IDs: > > > Error executing command: Error installing bundles: > > > Unable to install bundle foo > > > karaf@root> log:display > > > 2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console > > >| ? ? | 20 - > > > org.apache.karaf.shell.console - 2.4.0 | Exception caught while > executing > > > command > > > org.apache.karaf.shell.console.MultiException: Error installing > bundles: > > > Unable to install bundle foo > > > at > > > > > > org.apache.karaf.shell.console.MultiException.throwIf(MultiException.java:91) > > > at > > > > > > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:70) > > > at > > > > > > org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.karaf.shell.console.jline.Console.run(Console.java:196)[20:org.apache.karaf.shell.console:2.4.0] > > > at > > > > > > org.apache.karaf.shell.console.jline.DelayedStarted.run(DelayedStarted.java:79)[20:org.apache.karaf.shell.console:2.4.0] > > > Caused by: java.lang.Exception: Unable to install bundle foo > > > at > > > > > > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:45) > > > ... 11 more > > > Caused by: org.osgi.framework.BundleException: Unable to cache bundle: > > foo > > > at org.apache.felix.framework.Felix.installBundle(Felix.java:2878) > > > at > > > > > > org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165) > > > at > > > > > > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:43) > > > ... 11 more > > > Caused by: java.net.MalformedURLException: no protocol: foo > > > at java.net.URL.(URL.java:586)[:1.8.0_60] > > > at > > > > > > org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:254) > > > at > > > >
Re: Problems due to the endorsed java.lang.Exception
2016-03-21 10:06 GMT+01:00 Cristiano Costantini < cristiano.costant...@gmail.com>: > I've tested deleting the endorsed Jar on different clean installations of > Karaf and ServiceMix, > > I never get question marks [?:?] on the logs using the log:display command, > although some line in the printed stack trace does not include bundle > information. > Right. The behaviour I pasted earlier was on karaf master branch (so with pax logging / log4j v2). The pax logging / log4j v1 does not print anything when the information is not available. > > Here you can check what I've done and what has been logged out > https://gist.github.com/cristcost/4a5c554ccbb9577c690e > > > I'm going to repeat the tests with the endorsed Exception for comparing the > logs. > > Cristiano > > > Il giorno lun 21 mar 2016 alle ore 09:42 Cristiano Costantini < > cristiano.costant...@gmail.com> ha scritto: > > > > > > > now it is getting very weird... > > intrigued by the test with the protected method I have made another test: > > I have fully deleted the org.apache.karaf.exception-2.4.0.jar file from > the > > endorsed folder. > > And surprisingly, I still get the same logs information with the > > log:display command ! > > > > Please note that I am making this series of tests on ServiceMix 5.3.0, > > which is based on Karaf 2.4.0. > > This is the output of the test you have suggested: > > > > karaf@root> log:clear > > karaf@root> install foo > > Bundle IDs: > > Error executing command: Error installing bundles: > > Unable to install bundle foo > > karaf@root> log:display > > 2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console > >| ? ? | 20 - > > org.apache.karaf.shell.console - 2.4.0 | Exception caught while executing > > command > > org.apache.karaf.shell.console.MultiException: Error installing bundles: > > Unable to install bundle foo > > at > > > org.apache.karaf.shell.console.MultiException.throwIf(MultiException.java:91) > > at > > > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:70) > > at > > > org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.karaf.shell.console.jline.Console.run(Console.java:196)[20:org.apache.karaf.shell.console:2.4.0] > > at > > > org.apache.karaf.shell.console.jline.DelayedStarted.run(DelayedStarted.java:79)[20:org.apache.karaf.shell.console:2.4.0] > > Caused by: java.lang.Exception: Unable to install bundle foo > > at > > > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:45) > > ... 11 more > > Caused by: org.osgi.framework.BundleException: Unable to cache bundle: > foo > > at org.apache.felix.framework.Felix.installBundle(Felix.java:2878) > > at > > > org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165) > > at > > > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:43) > > ... 11 more > > Caused by: java.net.MalformedURLException: no protocol: foo > > at java.net.URL.(URL.java:586)[:1.8.0_60] > > at > > > org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:254) > > at > > > org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148) > > at > org.apache.felix.framework.cache.JarRevision.(JarRevision.java:77) > > at > > > org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:878) > > at > > > org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:550) > > at > > > org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:153) > > at > > org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:277) > > at org.apache.felix.framework.Felix.installBundle(Felix.java:2874) > > ... 13 more > > > > karaf@root> > > > > > > I repeat that this output is given from a Servicemix 5.3.0 where I have > > deleted the endorsed Jar. > > Do you expected this kind
Re: Problems due to the endorsed java.lang.Exception
That's not what is expected. It seems the OsgiThrowableRenderer from pax-logging does not do its job correctly in this case. 2016-03-21 9:41 GMT+01:00 Cristiano Costantini < cristiano.costant...@gmail.com>: > > > now it is getting very weird... > intrigued by the test with the protected method I have made another test: I > have fully deleted the org.apache.karaf.exception-2.4.0.jar file from the > endorsed folder. > And surprisingly, I still get the same logs information with the > log:display command ! > > Please note that I am making this series of tests on ServiceMix 5.3.0, > which is based on Karaf 2.4.0. > This is the output of the test you have suggested: > > karaf@root> log:clear > karaf@root> install foo > Bundle IDs: > Error executing command: Error installing bundles: > Unable to install bundle foo > karaf@root> log:display > 2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console >| ? ? | 20 - > org.apache.karaf.shell.console - 2.4.0 | Exception caught while executing > command > org.apache.karaf.shell.console.MultiException: Error installing bundles: > Unable to install bundle foo > at > > org.apache.karaf.shell.console.MultiException.throwIf(MultiException.java:91) > at > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:70) > at > > org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.karaf.shell.console.jline.Console.run(Console.java:196)[20:org.apache.karaf.shell.console:2.4.0] > at > > org.apache.karaf.shell.console.jline.DelayedStarted.run(DelayedStarted.java:79)[20:org.apache.karaf.shell.console:2.4.0] > Caused by: java.lang.Exception: Unable to install bundle foo > at > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:45) > ... 11 more > Caused by: org.osgi.framework.BundleException: Unable to cache bundle: foo > at org.apache.felix.framework.Felix.installBundle(Felix.java:2878) > at > > org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165) > at > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:43) > ... 11 more > Caused by: java.net.MalformedURLException: no protocol: foo > at java.net.URL.(URL.java:586)[:1.8.0_60] > at > > org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:254) > at > > org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148) > at org.apache.felix.framework.cache.JarRevision.(JarRevision.java:77) > at > > org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:878) > at > > org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:550) > at > > org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:153) > at > org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:277) > at org.apache.felix.framework.Felix.installBundle(Felix.java:2874) > ... 13 more > > karaf@root> > > > I repeat that this output is given from a Servicemix 5.3.0 where I have > deleted the endorsed Jar. > Do you expected this kind of logs Guillaume? > > I'll now make more tests with fully clean ServiceMix and fully clean Karaf > and let you know if the behavior persist. > > Cristiano > > > > > > Il giorno lun 21 mar 2016 alle ore 09:30 Guillaume Nodet < > gno...@apache.org> > ha scritto: > > > 2016-03-21 9:13 GMT+01:00 Cristiano Costantini < > > cristiano.costant...@gmail.com>: > > > > > Hi all, > > > > > > Guillaume, could it be that pax logging works also if using "protected" > > in > > > the getClassContext method? > > > > > > > In fact I'm testing and comparing the two options, but I see that also > > with > > > the solution of making the endorsed class method like this: > > > protected Class[] getClassContext() { > > > return classContext; > > > } > > > > > > I am still getting the same logs > > > with [bundleId:bundleSymbolicName:bundleVersion] information > >
Re: Problems due to the endorsed java.lang.Exception
I've tested deleting the endorsed Jar on different clean installations of Karaf and ServiceMix, I never get question marks [?:?] on the logs using the log:display command, although some line in the printed stack trace does not include bundle information. Here you can check what I've done and what has been logged out https://gist.github.com/cristcost/4a5c554ccbb9577c690e I'm going to repeat the tests with the endorsed Exception for comparing the logs. Cristiano Il giorno lun 21 mar 2016 alle ore 09:42 Cristiano Costantini < cristiano.costant...@gmail.com> ha scritto: > > > now it is getting very weird... > intrigued by the test with the protected method I have made another test: > I have fully deleted the org.apache.karaf.exception-2.4.0.jar file from the > endorsed folder. > And surprisingly, I still get the same logs information with the > log:display command ! > > Please note that I am making this series of tests on ServiceMix 5.3.0, > which is based on Karaf 2.4.0. > This is the output of the test you have suggested: > > karaf@root> log:clear > karaf@root> install foo > Bundle IDs: > Error executing command: Error installing bundles: > Unable to install bundle foo > karaf@root> log:display > 2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console >| ? ? | 20 - > org.apache.karaf.shell.console - 2.4.0 | Exception caught while executing > command > org.apache.karaf.shell.console.MultiException: Error installing bundles: > Unable to install bundle foo > at > org.apache.karaf.shell.console.MultiException.throwIf(MultiException.java:91) > at > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:70) > at > org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.karaf.shell.console.jline.Console.run(Console.java:196)[20:org.apache.karaf.shell.console:2.4.0] > at > org.apache.karaf.shell.console.jline.DelayedStarted.run(DelayedStarted.java:79)[20:org.apache.karaf.shell.console:2.4.0] > Caused by: java.lang.Exception: Unable to install bundle foo > at > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:45) > ... 11 more > Caused by: org.osgi.framework.BundleException: Unable to cache bundle: foo > at org.apache.felix.framework.Felix.installBundle(Felix.java:2878) > at > org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165) > at > org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:43) > ... 11 more > Caused by: java.net.MalformedURLException: no protocol: foo > at java.net.URL.(URL.java:586)[:1.8.0_60] > at > org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:254) > at > org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148) > at org.apache.felix.framework.cache.JarRevision.(JarRevision.java:77) > at > org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:878) > at > org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:550) > at > org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:153) > at > org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:277) > at org.apache.felix.framework.Felix.installBundle(Felix.java:2874) > ... 13 more > > karaf@root> > > > I repeat that this output is given from a Servicemix 5.3.0 where I have > deleted the endorsed Jar. > Do you expected this kind of logs Guillaume? > > I'll now make more tests with fully clean ServiceMix and fully clean Karaf > and let you know if the behavior persist. > > Cristiano > > > > > > Il giorno lun 21 mar 2016 alle ore 09:30 Guillaume Nodet < > gno...@apache.org> ha scritto: > >> 2016-03-21 9:13 GMT+01:00 Cristiano Costantini < >> cristiano.costant...@gmail.com>: >> >> > Hi all, >> > >> > Guillaume, could it be that pax logging works also if using "protected" >> in >> > the getClassContext method? >> >> >> > In fact I'm testing and comparing
Re: Problems due to the endorsed java.lang.Exception
now it is getting very weird... intrigued by the test with the protected method I have made another test: I have fully deleted the org.apache.karaf.exception-2.4.0.jar file from the endorsed folder. And surprisingly, I still get the same logs information with the log:display command ! Please note that I am making this series of tests on ServiceMix 5.3.0, which is based on Karaf 2.4.0. This is the output of the test you have suggested: karaf@root> log:clear karaf@root> install foo Bundle IDs: Error executing command: Error installing bundles: Unable to install bundle foo karaf@root> log:display 2016-03-21 09:38:02,339 | ERROR | l Console Thread | Console | ? ? | 20 - org.apache.karaf.shell.console - 2.4.0 | Exception caught while executing command org.apache.karaf.shell.console.MultiException: Error installing bundles: Unable to install bundle foo at org.apache.karaf.shell.console.MultiException.throwIf(MultiException.java:91) at org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:70) at org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.karaf.shell.console.jline.Console.run(Console.java:196)[20:org.apache.karaf.shell.console:2.4.0] at org.apache.karaf.shell.console.jline.DelayedStarted.run(DelayedStarted.java:79)[20:org.apache.karaf.shell.console:2.4.0] Caused by: java.lang.Exception: Unable to install bundle foo at org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:45) ... 11 more Caused by: org.osgi.framework.BundleException: Unable to cache bundle: foo at org.apache.felix.framework.Felix.installBundle(Felix.java:2878) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165) at org.apache.karaf.shell.osgi.InstallBundle.doExecute(InstallBundle.java:43) ... 11 more Caused by: java.net.MalformedURLException: no protocol: foo at java.net.URL.(URL.java:586)[:1.8.0_60] at org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:254) at org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148) at org.apache.felix.framework.cache.JarRevision.(JarRevision.java:77) at org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:878) at org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:550) at org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:153) at org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:277) at org.apache.felix.framework.Felix.installBundle(Felix.java:2874) ... 13 more karaf@root> I repeat that this output is given from a Servicemix 5.3.0 where I have deleted the endorsed Jar. Do you expected this kind of logs Guillaume? I'll now make more tests with fully clean ServiceMix and fully clean Karaf and let you know if the behavior persist. Cristiano Il giorno lun 21 mar 2016 alle ore 09:30 Guillaume Nodet ha scritto: > 2016-03-21 9:13 GMT+01:00 Cristiano Costantini < > cristiano.costant...@gmail.com>: > > > Hi all, > > > > Guillaume, could it be that pax logging works also if using "protected" > in > > the getClassContext method? > > > > In fact I'm testing and comparing the two options, but I see that also > with > > the solution of making the endorsed class method like this: > > protected Class[] getClassContext() { > > return classContext; > > } > > > > I am still getting the same logs > > with [bundleId:bundleSymbolicName:bundleVersion] information > > > > > > > I don't. Try with > > bundle:install foo > > log:display > I end up with lots of ~[?:?] instead of the actual bundle informations > when using a protected method. > If the @XmlTransient annotation is sufficient, that's the easiest fix. > But I agree it would be better to move that method as protected. We could > release a bug version of pax-logging to support this change. > > > > > > > > Il giorno dom 20 mar 2016 alle ore 09:24 Jean-Baptiste Onofré < > > j...@nanthr
Re: Problems due to the endorsed java.lang.Exception
2016-03-21 9:13 GMT+01:00 Cristiano Costantini < cristiano.costant...@gmail.com>: > Hi all, > > Guillaume, could it be that pax logging works also if using "protected" in > the getClassContext method? > In fact I'm testing and comparing the two options, but I see that also with > the solution of making the endorsed class method like this: > protected Class[] getClassContext() { > return classContext; > } > > I am still getting the same logs > with [bundleId:bundleSymbolicName:bundleVersion] information > > > I don't. Try with > bundle:install foo > log:display I end up with lots of ~[?:?] instead of the actual bundle informations when using a protected method. If the @XmlTransient annotation is sufficient, that's the easiest fix. But I agree it would be better to move that method as protected. We could release a bug version of pax-logging to support this change. > > > Il giorno dom 20 mar 2016 alle ore 09:24 Jean-Baptiste Onofré < > j...@nanthrax.net> ha scritto: > > > +1 > > > > I think @XmlTransient is sufficient and limit the impacts. > > > > Regards > > JB > > > > On 03/20/2016 09:17 AM, Cristiano Costantini wrote: > > > Hello all, > > > > > > I like the idea of having "bundle id, symbolic name and version" in the > > > exception logs, I've used it a lot and I think we should find a > solution > > > that is as clean as possible and works well by keep this enhanced > logging > > > capability alive. > > > > > > The solution of marking the method with @XmlTransient is good and would > > > fully solve the CXF problem (I'll try this one tomorrow morning and > give > > > you a confirmation about this approach). > > > > > > Also, JaxB sees it as a property because it is a getter, and try to > > > marshall it because JaxB default behavior is to marshall properties. > > > Then I propose also, for cleanliness to @Deprecate the getClassContext > > > method and create a new one called in a non property way, for example > > > simply classContext(), without the get. > > > > > > If Guillaume in pax-logging is using reflection and may be able to > access > > > the method even if it is protected, then it should be "protected", > again > > > for cleanliness. > > > > > > > > > I was thinking at what other problems could be caused by this > endorsement > > > of the class: > > > the underlying classContext field is correctly marked as transient, so > I > > > expect no problem due to serialization, even with third party libraries > > > (for example Kryo) which respect the transient modifier. > > > Except for JaxB, I don't know any other use case where exceptions may > be > > > accessed with reflection in search for methods. > > > > > > So to summarize: > > > > > > @XmlTransient @Deprecated public getClassContext() { ... } > > > + > > > protected classContext() { ... } > > > > > > seems to me the best option. > > > > > > > > > What do you think? > > > > > > Cristiano > > > > > > > > > > > > > > > > > > Il giorno dom 20 mar 2016 alle ore 04:04 Matt Sicker > > > ha > > > scritto: > > > > > >> If there's a way to fix this in log4j, that would be better. > > >> > > >> On 19 March 2016 at 06:02, James Carman > > >> wrote: > > >> > > >>> 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 > > >> 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.Secu
Re: Problems due to the endorsed java.lang.Exception
Hi all, Guillaume, could it be that pax logging works also if using "protected" in the getClassContext method? In fact I'm testing and comparing the two options, but I see that also with the solution of making the endorsed class method like this: protected Class[] getClassContext() { return classContext; } I am still getting the same logs with [bundleId:bundleSymbolicName:bundleVersion] information Il giorno dom 20 mar 2016 alle ore 09:24 Jean-Baptiste Onofré < j...@nanthrax.net> ha scritto: > +1 > > I think @XmlTransient is sufficient and limit the impacts. > > Regards > JB > > On 03/20/2016 09:17 AM, Cristiano Costantini wrote: > > Hello all, > > > > I like the idea of having "bundle id, symbolic name and version" in the > > exception logs, I've used it a lot and I think we should find a solution > > that is as clean as possible and works well by keep this enhanced logging > > capability alive. > > > > The solution of marking the method with @XmlTransient is good and would > > fully solve the CXF problem (I'll try this one tomorrow morning and give > > you a confirmation about this approach). > > > > Also, JaxB sees it as a property because it is a getter, and try to > > marshall it because JaxB default behavior is to marshall properties. > > Then I propose also, for cleanliness to @Deprecate the getClassContext > > method and create a new one called in a non property way, for example > > simply classContext(), without the get. > > > > If Guillaume in pax-logging is using reflection and may be able to access > > the method even if it is protected, then it should be "protected", again > > for cleanliness. > > > > > > I was thinking at what other problems could be caused by this endorsement > > of the class: > > the underlying classContext field is correctly marked as transient, so I > > expect no problem due to serialization, even with third party libraries > > (for example Kryo) which respect the transient modifier. > > Except for JaxB, I don't know any other use case where exceptions may be > > accessed with reflection in search for methods. > > > > So to summarize: > > > > @XmlTransient @Deprecated public getClassContext() { ... } > > + > > protected classContext() { ... } > > > > seems to me the best option. > > > > > > What do you think? > > > > Cristiano > > > > > > > > > > > > Il giorno dom 20 mar 2016 alle ore 04:04 Matt Sicker > ha > > scritto: > > > >> If there's a way to fix this in log4j, that would be better. > >> > >> On 19 March 2016 at 06:02, James Carman > >> wrote: > >> > >>> 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 > >> 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
Re: Problems due to the endorsed java.lang.Exception
+1 I think @XmlTransient is sufficient and limit the impacts. Regards JB On 03/20/2016 09:17 AM, Cristiano Costantini wrote: Hello all, I like the idea of having "bundle id, symbolic name and version" in the exception logs, I've used it a lot and I think we should find a solution that is as clean as possible and works well by keep this enhanced logging capability alive. The solution of marking the method with @XmlTransient is good and would fully solve the CXF problem (I'll try this one tomorrow morning and give you a confirmation about this approach). Also, JaxB sees it as a property because it is a getter, and try to marshall it because JaxB default behavior is to marshall properties. Then I propose also, for cleanliness to @Deprecate the getClassContext method and create a new one called in a non property way, for example simply classContext(), without the get. If Guillaume in pax-logging is using reflection and may be able to access the method even if it is protected, then it should be "protected", again for cleanliness. I was thinking at what other problems could be caused by this endorsement of the class: the underlying classContext field is correctly marked as transient, so I expect no problem due to serialization, even with third party libraries (for example Kryo) which respect the transient modifier. Except for JaxB, I don't know any other use case where exceptions may be accessed with reflection in search for methods. So to summarize: @XmlTransient @Deprecated public getClassContext() { ... } + protected classContext() { ... } seems to me the best option. What do you think? Cristiano Il giorno dom 20 mar 2016 alle ore 04:04 Matt Sicker ha scritto: If there's a way to fix this in log4j, that would be better. On 19 March 2016 at 06:02, James Carman wrote: 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 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 : 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 wrote: The getClassContext() method is used in pax-logging to render the exception in a nicer way. I don't have
Re: Problems due to the endorsed java.lang.Exception
Hello all, I like the idea of having "bundle id, symbolic name and version" in the exception logs, I've used it a lot and I think we should find a solution that is as clean as possible and works well by keep this enhanced logging capability alive. The solution of marking the method with @XmlTransient is good and would fully solve the CXF problem (I'll try this one tomorrow morning and give you a confirmation about this approach). Also, JaxB sees it as a property because it is a getter, and try to marshall it because JaxB default behavior is to marshall properties. Then I propose also, for cleanliness to @Deprecate the getClassContext method and create a new one called in a non property way, for example simply classContext(), without the get. If Guillaume in pax-logging is using reflection and may be able to access the method even if it is protected, then it should be "protected", again for cleanliness. I was thinking at what other problems could be caused by this endorsement of the class: the underlying classContext field is correctly marked as transient, so I expect no problem due to serialization, even with third party libraries (for example Kryo) which respect the transient modifier. Except for JaxB, I don't know any other use case where exceptions may be accessed with reflection in search for methods. So to summarize: @XmlTransient @Deprecated public getClassContext() { ... } + protected classContext() { ... } seems to me the best option. What do you think? Cristiano Il giorno dom 20 mar 2016 alle ore 04:04 Matt Sicker ha scritto: > If there's a way to fix this in log4j, that would be better. > > On 19 March 2016 at 06:02, James Carman > wrote: > > > 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 > 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. > > > >
Problems due to the endorsed java.lang.Exception
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 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
Re: Problems due to the endorsed java.lang.Exception
If there's a way to fix this in log4j, that would be better. On 19 March 2016 at 06:02, James Carman wrote: > 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 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 : > > > > > 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 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é : > > > > > > > > > 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 > > > > >
Re: Problems due to the endorsed java.lang.Exception
Since Karaf is now Java7+ and jaxb-api is also endorsed, you could likely just add @javax.xml.bind.annotation.XmlTransient to the getter. That said, the idea of adding public methods onto JDK level classes screams “bad idea” to me. Dan > On Mar 18, 2016, at 1:11 PM, Guillaume Nodet 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é : > >> 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 >>> 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/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problems due to the endorsed java.lang.Exception
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é : > 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 >> 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/
Re: Problems due to the endorsed java.lang.Exception
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 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é : > > > 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 > >> 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
Re: Problems due to the endorsed java.lang.Exception
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 : > 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 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é : > > > > > 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 > > >> 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 pro
Re: Problems due to the endorsed java.lang.Exception
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 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 : > > > 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 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é : > > > > > > > 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() { > > > >> retu
Re: Problems due to the endorsed java.lang.Exception
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 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