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 < [email protected]> 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 < > [email protected]> ha scritto: > >> 2016-03-21 10:06 GMT+01:00 Cristiano Costantini < >> [email protected]>: >> >> > 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 < >> > [email protected]> ha scritto: >> > >> > > mmmm >> > > >> > > 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.<init>(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.<init>(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.<init>(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 < >> > > [email protected]> ha scritto: >> > > >> > >> 2016-03-21 9:13 GMT+01:00 Cristiano Costantini < >> > >> [email protected]>: >> > >> >> > >> > 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é < >> > >> > [email protected]> 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 < >> > >> [email protected] >> > >> > > >> > >> > > 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 < >> > >> [email protected]> >> > >> > > >> 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 < >> > >> [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/ >> > >> > > >>>> >> > >> > > >>> >> > >> > > >> >> > >> > > >> >> > >> > > >> >> > >> > > >> -- >> > >> > > >> Matt Sicker <[email protected]> >> > >> > > >> >> > >> > > > >> > >> > > >> > >> > > -- >> > >> > > 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/ >> > >> >> > > >> > >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Red Hat, Open Source Integration >> >> Email: [email protected] >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> >
