> On Sep 5, 2015, at 5:47 PM, Benson Margulies <[email protected]> wrote: > > On Sat, Sep 5, 2015 at 5:26 PM, David Jencks <[email protected] > <mailto:[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.
I thought DOSGI was an implementation of remote OSGI services, which would be very different. But I don’t actually know. > >> >>> >>> >>> >>> >>>>> >>>>> 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? Don’t use anything but bnd, such as through the maven-bundle-plugin. I think the scr plugin is for the felix annotations… stay away. I strongly recommend configuring the maven-bundle-plugin to use a bnd.bnd file instead of trying to translate sensible bnd instructions into incomprehensible xml gibberish. I’m not sure what the default is in pre-bnd3, in bnd 3 the default is to find all the annotated classes. Otherwise specify -dsannotations: * I like to list them all explicitly so there’s an easy to find reference of all the DS components, but there’s probably a better way to do this that I don’t know of. david jencks > >> >> 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.
