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/content/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>
