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