Perfect. Thanks. It was always a bit unclear as to whether I was firing up
a new instance of HTTP server instead of reusing the instance specified in
the Jetty setup. It sounds though that as long as I specify uri and port
along with everything else I get the Jetty instance. That makes it a lot
easier because even if I want to use a different port in my Jetty, for
whatever reason, I can pass that port in from my cfg file and not have to
rebundle. That's how I normally do it. Such as:
<cxf:rsServer id="myRestEndpoint" address="${CXFServer}/resources"
serviceClass="com.foo.api.MyServicesAPI"> That really does make self
contained bundles, almost microservices, practical. And then one bundle
should be able to be the one that specifically sets up jaas, interceptors,
providers, etc. without the need for setting those up in all the separated
bundles. If nothing else I guess one can specify those on the cxf:bus to
make sure they are shared.
On Thu, Sep 8, 2016 at 1:08 AM, Christian Schneider <[email protected]
> wrote:
> It simply uses the existing HttpService so it will not start a new
> instance. You can even use the felix http service bundle instead. CXF will
> not care.
>
> I typically use this variant as it only needs one port for all services
> which makes it easier to manage.
>
> Christian
>
> 2016-09-08 0:25 GMT+02:00 Brad Johnson <[email protected]>:
>
>> Ah, very good. Does it start a new instance or does it piggyback
>> endpoints on the already running one configured in the etc dir? (Yeah, I
>> promised no more questions but a guy's just gotta know!)
>>
>> On Wed, Sep 7, 2016 at 4:01 PM, Christian Schneider <
>> [email protected]> wrote:
>>
>>> It depends on the address (like in plain cxf). If the address start with
>>> / then it will use the HttpService of the container. If it starts with
>>> http://server:port it will start a new jetty instance.
>>>
>>> Christian
>>>
>>> 2016-09-07 22:18 GMT+02:00 Brad Johnson <[email protected]>:
>>>
>>>> Thanks. Fuse launches Jetty by default I just wanted to make sure that
>>>> under the covers it wasn't using its own server instead.
>>>>
>>>> Brad
>>>>
>>>> On Wed, Sep 7, 2016 at 3:13 PM, Benson Margulies <[email protected]
>>>> > wrote:
>>>>
>>>>> On Wed, Sep 7, 2016 at 4:03 PM, Brad Johnson
>>>>> <[email protected]> wrote:
>>>>> > Christian,
>>>>> >
>>>>> > One last question and I promise to stop. In the simple example, when
>>>>> > starting the JaxWsFactory bean or its equivalent in Rs, that will
>>>>> not take
>>>>> > advantage of Jetty in a stack like ServiceMix or Fuse but use its own
>>>>> > in-built HttpServer. Do I have that correct? In a lot of cases it
>>>>> won't
>>>>> > really matter if I use the same address? The simple example uses:
>>>>> >
>>>>> > svrFactory.setAddress("http://localhost:9000/helloWorld";);
>>>>>
>>>>> That depends on which CXF transport you include. You can depend on
>>>>> pax-web, or you can let CXF launch jetty for itself.
>>>>> >
>>>>> > But if Jetty is running on port 8081 then if I change that to:
>>>>> > svrFactory.setAddress("http://localhost:8081/helloWorld";);
>>>>> >
>>>>> > will that simply use the Jetty port?
>>>>> >
>>>>> >
>>>>> > http://cxf.apache.org/docs/a-simple-jax-ws-service.html
>>>>> >
>>>>> > On Wed, Sep 7, 2016 at 10:44 AM, Brad Johnson <
>>>>> [email protected]>
>>>>> > wrote:
>>>>> >>
>>>>> >> Great, that's sort of how I figured it would work and I'l give it a
>>>>> shot.
>>>>> >>
>>>>> >> Brad
>>>>> >>
>>>>> >> On Wed, Sep 7, 2016 at 10:36 AM, Christian Schneider
>>>>> >> <[email protected]> wrote:
>>>>> >>>
>>>>> >>> In the old code the DS xml was manually created. The wiki is still
>>>>> at
>>>>> >>> that level.
>>>>> >>> In the new code the user only uses annotations and the maven bundle
>>>>> >>> plugin does the xml creation.
>>>>> >>>
>>>>> >>> Christian
>>>>> >>>
>>>>> >>>
>>>>> >>> On 07.09.2016 17:06, Brad Johnson wrote:
>>>>> >>>
>>>>> >>> http://cxf.apache.org/dosgi-ds-demo-page.html
>>>>> >>>
>>>>> >>> I see the SCR using XML in there but the annotations and SCR
>>>>> annotation
>>>>> >>> processor Maven plugin will automatically create that won't it.
>>>>> I'm so used
>>>>> >>> to using blueprint that it all feels a bit lopsided.
>>>>> >>>
>>>>> >>> On Wed, Sep 7, 2016 at 9:52 AM, Brad Johnson
>>>>> >>> <[email protected]> wrote:
>>>>> >>>>
>>>>> >>>> http://cxf.apache.org/docs/a-simple-jax-ws-service.html
>>>>> >>>>
>>>>> >>>> That looks a lot like what I'm looking for. Then I could set up a
>>>>> >>>> server bundle to do the repetitious stuff and have it export a
>>>>> service like
>>>>> >>>> SoapServer that takes a SoapInstallEvent and inside that I could
>>>>> send the
>>>>> >>>> interface, implementation and URI. Obviously the URI could be
>>>>> settable in
>>>>> >>>> cfg or properties file. Then when the bundle is being
>>>>> uninstalled it could
>>>>> >>>> send a SoapUninstallEvent. So the SoapServer OSGi service would
>>>>> only take
>>>>> >>>> those two events. Obviously I could set up the same thing for
>>>>> REST service.
>>>>> >>>>
>>>>> >>>> In that blueprint project I did that's pretty much how I handled
>>>>> it and
>>>>> >>>> it worked fine but I never knew about what the transport was
>>>>> really doing
>>>>> >>>> (Jetty, HTTP server, etc.) I don't like rolling my own code like
>>>>> that when
>>>>> >>>> it's far better letting the guys who know the libraries set it up.
>>>>> >>>>
>>>>> >>>> Brad
>>>>> >>>>
>>>>> >>>> On Wed, Sep 7, 2016 at 9:16 AM, Brad Johnson
>>>>> >>>> <[email protected]> wrote:
>>>>> >>>>>
>>>>> >>>>> I'll give it a look. That sounds like a move in the right
>>>>> direction.
>>>>> >>>>> In the short term I'll just set up the CXF server/endpoints with
>>>>> blueprint
>>>>> >>>>> and use the camel recipient list to route them to the correct
>>>>> bundle. That
>>>>> >>>>> doesn't work well for microservices. It probably would be OK
>>>>> for cxfrs
>>>>> >>>>> since it can take lists of interfaces to expose and those could
>>>>> be read from
>>>>> >>>>> an external configuration file. To move a service in or out one
>>>>> would just
>>>>> >>>>> modify the etc cfg file to add or remove the service interface
>>>>> and install
>>>>> >>>>> or uninstall the bundle. But I don't think that the CXF soap
>>>>> server can
>>>>> >>>>> take lists like that as far as I know.
>>>>> >>>>>
>>>>> >>>>> The CDI annotations added in to pax-cdi for using OSGi services
>>>>> right
>>>>> >>>>> from a bundle using only CDI and not a combination of CDI/DS is
>>>>> a very big
>>>>> >>>>> deal I think. That's going t be a real winner for a couple of
>>>>> reasons.
>>>>> >>>>> First it has fewer dependencies and annotations one must get
>>>>> right. Second
>>>>> >>>>> it will aid folks from other platforms who know how to use CDI
>>>>> but are not
>>>>> >>>>> as familiar with OSGi or DS. So making the move from any
>>>>> platform to the
>>>>> >>>>> Camel, pax-cdi platform is going to be much smoother.
>>>>> >>>>>
>>>>> >>>>> Brad
>>>>> >>>>>
>>>>> >>>>> On Wed, Sep 7, 2016 at 1:34 AM, Christian Schneider
>>>>> >>>>> <[email protected]> wrote:
>>>>> >>>>>>
>>>>> >>>>>> For CXF in DS or CDI you should try CXF DOSGi. I am currently
>>>>> woking
>>>>> >>>>>> on a new major version that is slimmer and should allow almost
>>>>> all CXF
>>>>> >>>>>> settings you can also do in blueprint.
>>>>> >>>>>> The idea is to publish the settings as OSGi services marked as
>>>>> >>>>>> intents. The new CXF DOSGi examples are all using DS and one
>>>>> example shows
>>>>> >>>>>> the setup of https with client cert authentication which was
>>>>> not possible
>>>>> >>>>>> before without blueprint.
>>>>> >>>>>>
>>>>> >>>>>> Christian
>>>>> >>>>>>
>>>>> >>>>>> 2016-09-07 0:19 GMT+02:00 Brad Johnson <
>>>>> [email protected]>:
>>>>> >>>>>>>
>>>>> >>>>>>> I'll definitely get my Nexus instance pointed at that repo and
>>>>> pull
>>>>> >>>>>>> it down. One of the biggest problems I'm going to have in the
>>>>> near term is
>>>>> >>>>>>> that the blueprint CXF allows for set up of everything to run
>>>>> on Jetty
>>>>> >>>>>>> fairly easily but to do the same thing on straight Java I end
>>>>> up having to
>>>>> >>>>>>> roll that myself. Perhaps an SCR/CDI library using the
>>>>> pax-cdi is in the
>>>>> >>>>>>> works once it has been released. I'll probably look at the
>>>>> Camel src code
>>>>> >>>>>>> for CXF to see how they do it internally with blueprint and
>>>>> attempt to
>>>>> >>>>>>> duplicate it.
>>>>> >>>>>>>
>>>>> >>>>>>> One of the frustrations I was having trying to do the CDI/SCR
>>>>> was
>>>>> >>>>>>> that I have it working perfectly well in one project but
>>>>> couldn't get it to
>>>>> >>>>>>> work correctly in the second project. I'm trying to make this
>>>>> so my bundles
>>>>> >>>>>>> can be microservices that when installed are picked up by the
>>>>> CXF Rest
>>>>> >>>>>>> and/or SOAP service and register themselves and when they are
>>>>> undeployed
>>>>> >>>>>>> automatically unregister. That's important in environments
>>>>> where you might
>>>>> >>>>>>> find out that one of the bundles is getting hammered by
>>>>> traffic on occasion
>>>>> >>>>>>> and that brings the whole bunch to a crawl. But if you can
>>>>> just uninstall
>>>>> >>>>>>> it and move it to a duplicate karaf/felix installation on
>>>>> another machine/VM
>>>>> >>>>>>> and have it auto deploy itself it makes that a snap.
>>>>> >>>>>>>
>>>>> >>>>>>> I did something with blueprint that was that way though I
>>>>> confess
>>>>> >>>>>>> some of the configurability was a bit overkill. Still, one
>>>>> bundle might
>>>>> >>>>>>> require badgerfish, as I had in a recent installation, while
>>>>> others did not.
>>>>> >>>>>>> Simply registering the bundle and having the SOAP/REST server
>>>>> pick it up
>>>>> >>>>>>> made that easy to configure. A bit of bundles as
>>>>> microservices. The only
>>>>> >>>>>>> way I can think of reasonably doing this now with just
>>>>> annotated classes is
>>>>> >>>>>>> if I could inject the blueprint create servers into my classes
>>>>> but I'm not
>>>>> >>>>>>> sure what they'd even look like in that context. What I ended
>>>>> up with is
>>>>> >>>>>>> creating my own JaxRSFactory and the equivalent with SOAP and
>>>>> starting them
>>>>> >>>>>>> up. Of course that meant they were running on the internal
>>>>> HTTP server and
>>>>> >>>>>>> not on something more suited to an enterprise environment.
>>>>> >>>>>>>
>>>>> >>>>>>> https://github.com/Ranx0r0x/Enjekt-Microservice
>>>>> >>>>>>>
>>>>> >>>>>>> On Tue, Sep 6, 2016 at 1:57 PM, Guillaume Nodet <
>>>>> [email protected]>
>>>>> >>>>>>> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>> You need to use the 1.0.0-SNAPSHOT version available from the
>>>>> >>>>>>>> following maven repository:
>>>>> >>>>>>>> https://oss.sonatype.org/conte
>>>>> nt/repositories/ops4j-snapshots
>>>>> >>>>>>>> I've just uploaded a new version to make sure it's up to date.
>>>>> >>>>>>>>
>>>>> >>>>>>>> 2016-09-06 20:50 GMT+02:00 Brad Johnson
>>>>> >>>>>>>> <[email protected]>:
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Is there a newer or extension bundle than:
>>>>> >>>>>>>>> pax-cdi-api-1.0.0.RC1.jar
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> I don't see these annotations in there an Eclipse can't find
>>>>> them.
>>>>> >>>>>>>>> org.ops4j.pax.cdi.api.Component
>>>>> >>>>>>>>> org.ops4j.pax.cdi.api.Immediate
>>>>> >>>>>>>>> org.ops4j.pax.cdi.api.Service
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> On Tue, Sep 6, 2016 at 11:09 AM, Guillaume Nodet
>>>>> >>>>>>>>> <[email protected]> wrote:
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> The new annotations are
>>>>> >>>>>>>>>> org.ops4j.pax.cdi.api.Component
>>>>> >>>>>>>>>> org.ops4j.pax.cdi.api.Immediate
>>>>> >>>>>>>>>> org.ops4j.pax.cdi.api.Service
>>>>> >>>>>>>>>> ...
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Those annotations are different from the SCR or DS
>>>>> annotations, so
>>>>> >>>>>>>>>> you clearly do not need the felix scr annotations bundle.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Guillaume
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> 2016-09-06 17:51 GMT+02:00 Brad Johnson
>>>>> >>>>>>>>>> <[email protected]>:
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> @gnodet
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> I have been using the new CDI along with Camel 2.17.3 and
>>>>> it
>>>>> >>>>>>>>>>> sounds as if I don't need the SCR at all then? So I'd be
>>>>> able to remove
>>>>> >>>>>>>>>>> the felix scr annotations dependency? The last element in
>>>>> the list which
>>>>> >>>>>>>>>>> I've italicized.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> <dependency>
>>>>> >>>>>>>>>>> <groupId>javax.enterprise</groupId>
>>>>> >>>>>>>>>>> <artifactId>cdi-api</artifactId>
>>>>> >>>>>>>>>>> </dependency>
>>>>> >>>>>>>>>>> <dependency>
>>>>> >>>>>>>>>>> <groupId>org.ops4j.pax.cdi</groupId>
>>>>> >>>>>>>>>>> <artifactId>pax-cdi-api</artifactId>
>>>>> >>>>>>>>>>> <version>1.0.0.RC1</version>
>>>>> >>>>>>>>>>> </dependency>
>>>>> >>>>>>>>>>> <dependency>
>>>>> >>>>>>>>>>> <groupId>org.apache.camel</groupId>
>>>>> >>>>>>>>>>> <artifactId>camel-cdi</artifactId>
>>>>> >>>>>>>>>>> </dependency>
>>>>> >>>>>>>>>>> <dependency>
>>>>> >>>>>>>>>>> <groupId>org.apache.felix</groupId>
>>>>> >>>>>>>>>>> <artifactId>org.apache.felix.scr.annotations</artifactId>
>>>>> >>>>>>>>>>> </dependency>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> On Tue, Sep 6, 2016 at 10:47 AM, Brad Johnson
>>>>> >>>>>>>>>>> <[email protected]> wrote:
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> @gnodet
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Thanks for the info regarding the
>>>>> >>>>>>>>>>>> @OsgiServe/@OsgiServiceProvider. Perhaps that's where I
>>>>> go the idea that
>>>>> >>>>>>>>>>>> one needed to specify start up order on bundles. In some
>>>>> recent test
>>>>> >>>>>>>>>>>> projects I have been using the Felix SCR but most of the
>>>>> testing has been
>>>>> >>>>>>>>>>>> using the CamelCDI runner as it is very fast. That
>>>>> obviously creates some
>>>>> >>>>>>>>>>>> problems with having to double annotate some items for
>>>>> Inject vs Reference
>>>>> >>>>>>>>>>>> and so on and the fact that CDI isn't going to respect
>>>>> bundle boundaries
>>>>> >>>>>>>>>>>> inside the test. But that isn't a huge problem because
>>>>> in the context of
>>>>> >>>>>>>>>>>> testing it isn't like I have 300 bundles running. It's
>>>>> just a few
>>>>> >>>>>>>>>>>> application bundles and their dependencies.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> It does mean I'll have to get ready to deal with some
>>>>> errors
>>>>> >>>>>>>>>>>> when moving from the IDE environment over to the
>>>>> Karaf/felix environment but
>>>>> >>>>>>>>>>>> for development/testing speed it definitely seems worth
>>>>> it.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> I'm so used to using CamelBlueprintTestSupport and
>>>>> blueprint.xml
>>>>> >>>>>>>>>>>> that all of this still feels a bit left handed -- "If I
>>>>> were doing this in
>>>>> >>>>>>>>>>>> blueprint, this what I'd do...."
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> On Mon, Sep 5, 2016 at 6:38 AM, Guillaume Nodet
>>>>> >>>>>>>>>>>> <[email protected]> wrote:
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> I don't really recommend using the @OsgiService /
>>>>> >>>>>>>>>>>>> @OsgiServiceProvider of Pax-CDI.
>>>>> >>>>>>>>>>>>> The main reason is that if the bundles are not started
>>>>> in the
>>>>> >>>>>>>>>>>>> correct order, the bean validation will simply fail and
>>>>> your CDI app won't
>>>>> >>>>>>>>>>>>> be created at all.
>>>>> >>>>>>>>>>>>> I'd really recommend to look at the new annotations of
>>>>> Pax-CDI
>>>>> >>>>>>>>>>>>> which haven't been released yet (in 1.0.0-SNAPSHOT).
>>>>> They are very similar
>>>>> >>>>>>>>>>>>> to the DS semantics (and they actually use part of Felix
>>>>> SCR implementation
>>>>> >>>>>>>>>>>>> as the core engine). The lifecycle of the CDI beans is
>>>>> similar to those of
>>>>> >>>>>>>>>>>>> DS, so the dependency mechanism is really
>>>>> straightforward from a user point
>>>>> >>>>>>>>>>>>> of view.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Cheers,
>>>>> >>>>>>>>>>>>> Guillaume
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> 2016-09-02 19:46 GMT+02:00 Brad Johnson
>>>>> >>>>>>>>>>>>> <[email protected]>:
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Matt,
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> For the past few weeks I've been working with the Camel
>>>>> 2.17
>>>>> >>>>>>>>>>>>>> CDI and it's marvelous. I've been using blueprint for
>>>>> a few years now and I
>>>>> >>>>>>>>>>>>>> won't be going back to twiddling XML unless I have to
>>>>> (I'm not sure how to
>>>>> >>>>>>>>>>>>>> set up CXF server without it right now). But the CDI
>>>>> test runner is fast
>>>>> >>>>>>>>>>>>>> and a snap to use. The annotation automated wire up and
>>>>> RouteBuilder
>>>>> >>>>>>>>>>>>>> automatic running is just like you'd think ought to be.
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> The pax-cdi implementation actually creates blueprint
>>>>> proxies
>>>>> >>>>>>>>>>>>>> for annotations like @OSGiServiceProvider and will
>>>>> inject it where you
>>>>> >>>>>>>>>>>>>> specify the service consumer. The only caveat to the
>>>>> CDI test runner is that
>>>>> >>>>>>>>>>>>>> it is not OSGi based but uses Weld. So you have to be
>>>>> careful about what
>>>>> >>>>>>>>>>>>>> you test but I can live with that. Truly stunning when
>>>>> one sees a
>>>>> >>>>>>>>>>>>>> technology that works almost like magic - like you'd
>>>>> dream it should work.
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> On Fri, Sep 2, 2016 at 12:04 PM, Matt Sicker
>>>>> >>>>>>>>>>>>>> <[email protected]> wrote:
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> On 2 September 2016 at 11:30, Timothy Ward
>>>>> >>>>>>>>>>>>>>> <[email protected]> wrote:
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> As things stand currently blueprint is most widely
>>>>> used for
>>>>> >>>>>>>>>>>>>>>> working with Camel. From what I can tell configuring
>>>>> Camel is horrible, and
>>>>> >>>>>>>>>>>>>>>> my understanding is that the main advantage of
>>>>> blueprint is that there is a
>>>>> >>>>>>>>>>>>>>>> huge amount of ready-built Camel integration
>>>>> available. If Camel had a
>>>>> >>>>>>>>>>>>>>>> nicer, container agnostic configuration mechanism
>>>>> then I would see little
>>>>> >>>>>>>>>>>>>>>> reason to choose blueprint over DS.
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> This right here is exactly how I feel. If there was a
>>>>> well
>>>>> >>>>>>>>>>>>>>> supported way of simply using DS instead of Blueprint
>>>>> with Camel, then I'd
>>>>> >>>>>>>>>>>>>>> drop Blueprint in a single sprint and never look back.
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> --
>>>>> >>>>>>>>>>>>> ------------------------
>>>>> >>>>>>>>>>>>> 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/
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> --
>>>>> >>>>>>>> ------------------------
>>>>> >>>>>>>> Guillaume Nodet
>>>>> >>>>>>>> ------------------------
>>>>> >>>>>>>> Red Hat, Open Source Integration
>>>>> >>>>>>>>
>>>>> >>>>>>>> Email: [email protected]
>>>>> >>>>>>>> Web: http://fusesource.com
>>>>> >>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>> >>>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> --
>>>>> >>>>>> --
>>>>> >>>>>> Christian Schneider
>>>>> >>>>>> http://www.liquid-reality.de
>>>>> >>>>>>
>>>>> >>>>>> Open Source Architect
>>>>> >>>>>> http://www.talend.com
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> Christian Schneider
>>>>> >>> http://www.liquid-reality.de
>>>>> >>>
>>>>> >>> Open Source Architect
>>>>> >>> http://www.talend.com
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
>>>
>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
>
