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>:
> 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 <
> 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
> > >
> > >
> > >
> > 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 <
> > boa...@gmail.com
> > > >
> > > > 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 <
> ja...@carmanconsulting.com
> > >
> > > > >> 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 <
> gno...@apache.org
> > >
> > > > >> 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 <boa...@gmail.com>:
> > > > >>>>
> > > > >>>>> What's wrong with the class context from
> > > > >>>>> ReflectionUtil.getCurrentStackTrace() that requires a custom
> > > > >>>> implementation
> > > > >>>>> of Exception?
> > > > >>>>>
> > > > >>>>> On 18 March 2016 at 12:11, Guillaume Nodet <gno...@apache.org>
> > > > >> wrote:
> > > > >>>>>
> > > > >>>>>> The getClassContext() method is used in pax-logging to render
> > the
> > > > >>>>> exception
> > > > >>>>>> in a nicer way.
> > > > >>>>>> I don't have any problem moving the qualifier to protected or
> > > > >>> whatever,
> > > > >>>>> but
> > > > >>>>>> we'd need to change the code in pax-logging
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
> > > > >>>>>>
> > > > >>>>>> It should not be a big deal, but the current code expect the
> > > method
> > > > >>> to
> > > > >>>> be
> > > > >>>>>> public unfortunately.
> > > > >>>>>>
> > > > >>>>>> Guillaume
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré <
> > j...@nanthrax.net
> > > >:
> > > > >>>>>>
> > > > >>>>>>> Hi Cristiano,
> > > > >>>>>>>
> > > > >>>>>>> I think you are right, it's probably something existing for a
> > > > >>> while.
> > > > >>>>> I'm
> > > > >>>>>>> just surprised that you encountered now.
> > > > >>>>>>>
> > > > >>>>>>> Let me check your detailed use case that you sent previously.
> > > > >>>>>>>
> > > > >>>>>>> Regards
> > > > >>>>>>> JB
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
> > > > >>>>>>>
> > > > >>>>>>>> Hello all,
> > > > >>>>>>>>
> > > > >>>>>>>> it is some days I was having troubles using CXF services on
> > > > >>>> ServiceMix
> > > > >>>>>>>> (and
> > > > >>>>>>>> it is some days I spam on the mailing list of ServiceMix,
> > Camel
> > > > >>> and
> > > > >>>>> CXF
> > > > >>>>>>>> :-D
> > > > >>>>>>>> ) and I've finally come to the source of my issues which are
> > due
> > > > >>> to
> > > > >>>>> the
> > > > >>>>>>>> "endorsed" java.lang.Exception which is used by Karaf:
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
> > > > >>>>>>>>
> > > > >>>>>>>> My problem is due to the fact that this class has a public
> > > > >>> property,
> > > > >>>>>>>> public Class[] getClassContext() {
> > > > >>>>>>>> return classContext;
> > > > >>>>>>>> }
> > > > >>>>>>>> which is seen by JaxB at runtime inside Karaf which cause it
> > to
> > > > >>>>> marshall
> > > > >>>>>>>> the Exception in SOAP services with a wrong XML, an XML
> which
> > > > >>>> include
> > > > >>>>>>>> <classContext> tags.
> > > > >>>>>>>>
> > > > >>>>>>>> The class in Karaf has not changed since committed by
> > Guillaume
> > > > >>>> Nodet
> > > > >>>>> in
> > > > >>>>>>>> 2010, so this issue with CXF has probably always been there.
> > > > >>>>>>>>
> > > > >>>>>>>> In my opinion, this getter should be private or protected
> as I
> > > > >>> guess
> > > > >>>>> it
> > > > >>>>>> is
> > > > >>>>>>>> only used on the nested class method's getThrowableContext
> (it
> > > > >> is
> > > > >>> a
> > > > >>>>>>>> replacement for the JRE's class, I don't think there are
> > > > >> external
> > > > >>>>>> project
> > > > >>>>>>>> using this modification of the Exception class).
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> To confirm my thesis, I've hacked the
> > > > >>>>>> org.apache.karaf.exception-2.4.0.jar
> > > > >>>>>>>> inside the lib/endorsed folder with a class compiled by
> myself
> > > > >>> where
> > > > >>>>>> I've
> > > > >>>>>>>> changed the method to
> > > > >>>>>>>> private Class[] getClassContext() {
> > > > >>>>>>>> return classContext;
> > > > >>>>>>>> }
> > > > >>>>>>>> and with this hack, Karaf has continued to work (and my CXF
> > > > >>> service
> > > > >>>>> now
> > > > >>>>>>>> works properly).
> > > > >>>>>>>>
> > > > >>>>>>>> Do you think there are potential side effects in this fix?
> > > > >>>>>>>> Do you need me to open an issue on Jira to handle the
> problem?
> > > > >>>>>>>> If it is confirmed that the fix of making this method
> private,
> > > > >> do
> > > > >>>> you
> > > > >>>>>>>> think
> > > > >>>>>>>> it could be included soon on the next Karaf Release?
> > > > >>>>>>>>
> > > > >>>>>>>> Thank you very much to all,
> > > > >>>>>>>> Cristiano
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>> --
> > > > >>>>>>> Jean-Baptiste Onofré
> > > > >>>>>>> jbono...@apache.org
> > > > >>>>>>> http://blog.nanthrax.net
> > > > >>>>>>> Talend - http://www.talend.com
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> --
> > > > >>>>>> ------------------------
> > > > >>>>>> Guillaume Nodet
> > > > >>>>>> ------------------------
> > > > >>>>>> Red Hat, Open Source Integration
> > > > >>>>>>
> > > > >>>>>> Email: gno...@redhat.com
> > > > >>>>>> Web: http://fusesource.com
> > > > >>>>>> Blog: http://gnodet.blogspot.com/
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>> Matt Sicker <boa...@gmail.com>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> ------------------------
> > > > >>>> Guillaume Nodet
> > > > >>>> ------------------------
> > > > >>>> Red Hat, Open Source Integration
> > > > >>>>
> > > > >>>> Email: gno...@redhat.com
> > > > >>>> Web: http://fusesource.com
> > > > >>>> Blog: http://gnodet.blogspot.com/
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Matt Sicker <boa...@gmail.com>
> > > > >>
> > > > >
> > > >
> > > > --
> > > > 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/
> >
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
