Re: Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

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

[Cristiano Costantini]

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
> > >
> >
> 

Re: Problems due to the endorsed java.lang.Exception

[Guillaume Nodet]

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

[Guillaume Nodet]

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

[Cristiano Costantini]

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 

Re: Problems due to the endorsed java.lang.Exception

[Guillaume Nodet]

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
> > 
> > 
> > >>>

Re: Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

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)
>  

Re: Problems due to the endorsed java.lang.Exception

[Jean-Baptiste Onofré]

+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 

Re: Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

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 

Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

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

[Daniel Kulp]

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

[Guillaume Nodet]

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

[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 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

[Guillaume Nodet]

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.
> > >>
> 

Re: Problems due to the endorsed java.lang.Exception

[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