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