karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Problems due to the endorsed java.lang.Exception
Date Mon, 21 Mar 2016 09:27:39 GMT
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