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 09:43:16 GMT
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