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/content/repositories/ops4j-snapshot >>> s >>> >>>>>>>> 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> >
