On Sat, Sep 5, 2015 at 5:26 PM, David Jencks <[email protected]> wrote: > >> On Sep 5, 2015, at 5:08 PM, Benson Margulies <[email protected]> wrote: >> >> On Sat, Sep 5, 2015 at 4:56 PM, David Jencks <[email protected]> wrote: >>> >>>> On Sep 5, 2015, at 3:09 PM, Benson Margulies <[email protected]> wrote: >>>> >>>> On Sat, Sep 5, 2015 at 1:54 PM, David Jencks <[email protected]> >>>> wrote: >>>>> I’d suggest ditching blueprint and using ds. >>>> >>>> I might, except ... >>>> >>>> 1) CXF has a blueprint integration, and not a DS integration. >>> >>> What does this integration do? IIRC blueprint doesn’t let you create your >>> own component instances either so I’d guess this must do something like >>> register certain blueprint components as jax* thingies in cxf? >> >> The following publishes a blueprint bean as a CXF restful service, >> registered with the whiteboard. CXF does not have DS metadata, so if I >> wanted to do this with DS, I'd have to write out the code myself, and >> I would have to research the particular step needed to get CXF to >> nestle into the whiteboard. I know what the Java equivalent of this is >> -- except for the connection to the whiteboard. >> >> <jaxrs:server id='workerJaxrsService' address="/worker"> >> <jaxrs:serviceBeans> >> <ref component-id="workerService"/> >> </jaxrs:serviceBeans> >> <jaxrs:providers> >> </jaxrs:providers> >> </jaxrs:server> > > Well, this seems like a really osgi-unfriendly approach. I realize this > isn’t the cxf list….. but I’d expect an approach like the jndi and jmx OSGI > specs (and I think http and http-whiteboard) take where you register an OSGI > service with some particular service properties and those are used to expose > the service in the appropriate “container” would be universal and really > simple to implement.
Well, they also have the full DOSGi hog, but I'm not going there, and I'm not sure it's relevant. > >> >> >> >> >>>> >>>> 2) Can you suggest a DS tutorial that does not lead straight into a >>>> maze of twisty passages related to BND versus Felix annotations, >>>> plugins, and processors? >>> >>> Well, I use the spec :-). Ignore any non-spec annotations and any claims >>> they are good for anything :-) (except the new bnd xml meta-annotation, for >>> which however there are no publicly available useful examples of yet). >>> >>> I guess it’s time for me to write such a tutorial …. >> >> Please do. Using blueprint is like a trip in a time machine to the >> olden times of Spring. I've read the spec, but does not illuminate >> what combination of Maven dependencies plugins (and BND plugins?) that >> will result in anything except a horrible wiring error about 'must be >> at compile time' which was my reward for trying to follow the tutorial >> I found. I can probably persuade my friends at CXF to help me with >> that part if I could get over the proverbial hump at all. > > hmmmm….. if you use bnd with gradle, the felix maven-bundle-plugin, or the > bndtools bundle-maven-plugin, and use only spec DS annotations, I would not > expect you to have any issues. If you use some other annotations, all bets > are off as far as I’m concerned. See, here's where I'm disoriented. Isn't there a separate 'scr' maven plugin in felix that I have to configure as well? Do I use _dsannotation or the other thing in maven-bundle-plugin, since I found conflicting instructions in different places? > > The bnd bndtests DSAnnotationTest has a really lot of examples although it > may be hard to understand what exactly is going on as it is run in grade and > there is bnd setup in code for each test. > > david jencks > > >> >> Thanks, as it were, in advance -- benson >> >> >>> >>> thanks >>> david jencks >>> >>>> >>>> >>>>> >>>>> david jencks >>>>> >>>>>> On Sep 5, 2015, at 1:38 PM, Benson Margulies <[email protected]> >>>>>> wrote: >>>>>> On Sat, Sep 5, 2015 at 1:33 PM, Benson Margulies <[email protected]> >>>>>> wrote: >>>>>>> org.apache.aries.blueprint.synchronous=true >>>>>> >>>>>> Unfortunately for me, I see that >>>>>> org.apache.aries.blueprint.synchronous=true is already in the default >>>>>> config.properties, so I'm puzzled. >>>>> >>> >
