karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cristiano Costantini <cristiano.costant...@gmail.com>
Subject Re: Problems due to the endorsed java.lang.Exception
Date Mon, 21 Mar 2016 08:41:58 GMT
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 <gnodet@apache.org>
ha scritto:

> 2016-03-21 9:13 GMT+01:00 Cristiano Costantini <
> cristiano.costantini@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é <
> > jb@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 <
> boards@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 <james@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 <gnodet@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 <boards@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 <gnodet@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é <
> jb@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é
> > > >>>>>>> jbonofre@apache.org
> > > >>>>>>> http://blog.nanthrax.net
> > > >>>>>>> Talend - http://www.talend.com
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> ------------------------
> > > >>>>>> Guillaume Nodet
> > > >>>>>> ------------------------
> > > >>>>>> Red Hat, Open Source Integration
> > > >>>>>>
> > > >>>>>> Email: gnodet@redhat.com
> > > >>>>>> Web: http://fusesource.com
> > > >>>>>> Blog: http://gnodet.blogspot.com/
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Matt Sicker <boards@gmail.com>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> ------------------------
> > > >>>> Guillaume Nodet
> > > >>>> ------------------------
> > > >>>> Red Hat, Open Source Integration
> > > >>>>
> > > >>>> Email: gnodet@redhat.com
> > > >>>> Web: http://fusesource.com
> > > >>>> Blog: http://gnodet.blogspot.com/
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Matt Sicker <boards@gmail.com>
> > > >>
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbonofre@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message