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