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/*reposito*ries/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 >> <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> >> > >
