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 15:43:21 GMT
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.costantini@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 <
> gnodet@apache.org> ha scritto:
>
>> 2016-03-21 10:06 GMT+01:00 Cristiano Costantini <
>> cristiano.costantini@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.costantini@gmail.com> 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 <
>> > > 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/
>> > >>
>> > >
>> >
>>
>>
>>
>> --
>> ------------------------
>> 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