Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
MIME-Version: 1.0
References: 
 <CAAPbCXjT5RDapx=Kt5K5-onF6cbM4mE_Awq9Kqjc+cVXXx6PtQ@mail.gmail.com>
 <56EC2CF3.6050708@nanthrax.net>
 <CAA66TpoWH1RpKqo0aiDxJsyq2+sJrwrej740yf+SFE0sf3M11g@mail.gmail.com>
 <CACmp6kpEyJ5OVMQbOSFGgjtMgpwN2TJMC0XC5pTtyeXLdcz68A@mail.gmail.com>
 <CAA66Tpoue7b5o=1oHGXUFccdPdS4f=KRAMf_YDfuyPU1upa__g@mail.gmail.com>
 <CALznzY4DKBD4Wj8pHr5K47BK0PiFsGyFsNuKNLZ3_58DHeCc2Q@mail.gmail.com>
 <CACmp6kqM+msa+NKfA_bH8-5pzBfQu2MmhRF6d3nxHqcmOsnrmg@mail.gmail.com>
 <CAAPbCXhHFG35DCyv_e_BhY1-1Vfi54iiizmXc640WJnqVyBb5g@mail.gmail.com>
 <56EE5E44.4060701@nanthrax.net>
 <CAAPbCXgo+cZnA3poKeVZB2rNhBQp2J6D53NnM1E7P_TKkn-L=Q@mail.gmail.com>
 <CAA66TpoUbUfCojtAw3n0A=o5-89y73A9YKLdRLpwWp9PhD2LHQ@mail.gmail.com>
 <CAAPbCXg20BJsnKP-abb_qtvdENo9goX3LQ5553iVc79jfbWpiQ@mail.gmail.com>
In-Reply-To: 
 <CAAPbCXg20BJsnKP-abb_qtvdENo9goX3LQ5553iVc79jfbWpiQ@mail.gmail.com>
From: Cristiano Costantini <cristiano.costantini@gmail.com>
Date: Mon, 21 Mar 2016 09:06:23 +0000
Message-ID: 
 <CAAPbCXh5xJYVfhYJGaeuPgh2bkMjeFL8b9uC8Kgmgyus5tF+kA@mail.gmail.com>
Subject: Re: Problems due to the endorsed java.lang.Exception
To: dev <dev@karaf.apache.org>
Content-Type: multipart/alternative; boundary=001a1133f752c8e24f052e8b6902

--001a1133f752c8e24f052e8b6902
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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 t=
he
> 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(OsgiCommandSupp=
ort.java:38)[20:org.apache.karaf.shell.console:2.4.0]
> at
> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractComm=
and.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.ap=
ache.karaf.shell.console:2.4.0]
> at
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[20:org.ap=
ache.karaf.shell.console:2.4.0]
> at
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionIm=
pl.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.ja=
va: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: fo=
o
> at org.apache.felix.framework.Felix.installBundle(Felix.java:2878)
> at
> org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextI=
mpl.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:7=
7)
> at
> org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation=
(BundleArchive.java:878)
> at
> org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchi=
ve.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 Kara=
f
> 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 cou=
ld
>> release a bug version of  pax-logging to support this change.
>>
>>
>> >
>> >
>> > Il giorno dom 20 mar 2016 alle ore 09:24 Jean-Baptiste Onofr=C3=A9 <
>> > 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" i=
n
>> 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 an=
d
>> > give
>> > > > you a confirmation about this approach).
>> > > >
>> > > > Also, JaxB sees it as a property because it is a getter, and try t=
o
>> > > > marshall it because JaxB default behavior is to marshall propertie=
s.
>> > > > 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.  I=
s
>> > 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, a=
nd
>> > > >> 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.jav=
a: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(ActionC=
ommand.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.jav=
a:1142)
>> > > >>>> [?:?]
>> > > >>>>
>> > > >>>> at
>> > > >>>>
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> >
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja=
va: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-l=
og4j2/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-s=
ervice/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=C3=A9 <
>> 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 ar=
e
>> 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 i=
t
>> to
>> > > >>>>> marshall
>> > > >>>>>>>> the Exception in SOAP services with a wrong XML, an XML whi=
ch
>> > > >>>> 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 a=
s
>> 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=C3=A9
>> > > >>>>>>> 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=C3=A9
>> > > 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/
>>
>

--001a1133f752c8e24f052e8b6902--