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/*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> >>>> >>> >>> >> > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > >
