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 <[email protected]> ha scritto: > 2016-03-21 10:06 GMT+01:00 Cristiano Costantini < > [email protected]>: > > > 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 < > > [email protected]> 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 < > > > [email protected]> ha scritto: > > > > > >> 2016-03-21 9:13 GMT+01:00 Cristiano Costantini < > > >> [email protected]>: > > >> > > >> > 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é < > > >> > [email protected]> 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 < > > >> [email protected] > > >> > > > > >> > > 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 < > > >> [email protected]> > > >> > > >> 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 < > > >> [email protected]> > > >> > > >> 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 <[email protected]>: > > >> > > >>>> > > >> > > >>>>> 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 < > [email protected] > > > > > >> > > >> 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é < > > >> [email protected] > > >> > >: > > >> > > >>>>>> > > >> > > >>>>>>> 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é > > >> > > >>>>>>> [email protected] > > >> > > >>>>>>> http://blog.nanthrax.net > > >> > > >>>>>>> Talend - http://www.talend.com > > >> > > >>>>>>> > > >> > > >>>>>> > > >> > > >>>>>> > > >> > > >>>>>> > > >> > > >>>>>> -- > > >> > > >>>>>> ------------------------ > > >> > > >>>>>> Guillaume Nodet > > >> > > >>>>>> ------------------------ > > >> > > >>>>>> Red Hat, Open Source Integration > > >> > > >>>>>> > > >> > > >>>>>> Email: [email protected] > > >> > > >>>>>> Web: http://fusesource.com > > >> > > >>>>>> Blog: http://gnodet.blogspot.com/ > > >> > > >>>>>> > > >> > > >>>>> > > >> > > >>>>> > > >> > > >>>>> > > >> > > >>>>> -- > > >> > > >>>>> Matt Sicker <[email protected]> > > >> > > >>>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> -- > > >> > > >>>> ------------------------ > > >> > > >>>> Guillaume Nodet > > >> > > >>>> ------------------------ > > >> > > >>>> Red Hat, Open Source Integration > > >> > > >>>> > > >> > > >>>> Email: [email protected] > > >> > > >>>> Web: http://fusesource.com > > >> > > >>>> Blog: http://gnodet.blogspot.com/ > > >> > > >>>> > > >> > > >>> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> Matt Sicker <[email protected]> > > >> > > >> > > >> > > > > > >> > > > > >> > > -- > > >> > > Jean-Baptiste Onofré > > >> > > [email protected] > > >> > > http://blog.nanthrax.net > > >> > > Talend - http://www.talend.com > > >> > > > > >> > > > >> > > >> > > >> > > >> -- > > >> ------------------------ > > >> Guillaume Nodet > > >> ------------------------ > > >> Red Hat, Open Source Integration > > >> > > >> Email: [email protected] > > >> Web: http://fusesource.com > > >> Blog: http://gnodet.blogspot.com/ > > >> > > > > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ >
