If you use ds then you can always override any service property using a config. This allows to dynamically change the address at runtime.
Christian Am 08.09.2016 16:39 schrieb "Brad Johnson" <[email protected]>: > 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> >> > >
