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>
