Christian, you might recall that I got into problems with configuration issues, and you plan to address the issues I ran into in 2.0. I can dig that mail up again if you don't still have it. Thus 'not ready yet.'
On Mon, Aug 15, 2016 at 1:30 PM, Christian Schneider <[email protected]> wrote: > Hi Benson, > > would be great to get some feedback about your experiences using dOSGi. As > we are approaching the 2.0 version now is the best time to get important > features in. > > Christian > > 2016-08-15 19:24 GMT+02:00 Benson Margulies <[email protected]>: >> >> Correct. I tried the dOSGi stuff, and it wasn't really ready to do >> what I needed to do. >> >> On Mon, Aug 15, 2016 at 1:17 PM, David Jencks <[email protected]> >> wrote: >> > Just to see if I understand what you are doing, this approach does not >> > involve the osgi service registry in any way for the REST service >> > implementation object? You are directly registering the component instance >> > with CXF, and there is no need for it to expose any service interfaces at >> > all? >> > >> > thanks >> > david jencks >> > >> >> On Aug 15, 2016, at 10:10 AM, Benson Margulies <[email protected]> >> >> wrote: >> >> >> >> I do this by making DS @Activate methods call the CXF API to publish >> >> REST services. >> >> >> >> >> >> On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis <[email protected]> >> >> wrote: >> >>> Hi Marc, >> >>> >> >>> The OSGi Remote Services specification (and the associated Remote >> >>> Service >> >>> Admin sepc) defines a standardized way to export OSGi services for >> >>> remote >> >>> access. The specification is defined in a way that allows the use of >> >>> arbitrary distribution providers that are responsible for making the >> >>> OSGi >> >>> service accessible from outside of the OSGi process. >> >>> >> >>> ECF [1] has an implementation of these specs that supports many >> >>> distribution >> >>> providers [2], including two that I'm working on now that supports any >> >>> Jax-RS implementation (i.e. both CXF and Jersey). These two >> >>> distribution >> >>> providers are here [3] and I'm finalizing them for an initial release. >> >>> Note that for these providers, in addition to specifying jax-rs >> >>> resources >> >>> via OSGi services, the jax-rs configuration (e.g. >> >>> MessageBodyReader/Writers, >> >>> Features, etc) can also be specified via OSGi services. >> >>> >> >>> Scott >> >>> >> >>> [1] https://wiki.eclipse.org/ECF >> >>> [2] https://wiki.eclipse.org/Distribution_Providers >> >>> [3] https://github.com/ECF/JaxRSProviders >> >>> >> >>> On 8/15/2016 8:21 AM, Marc Durand wrote: >> >>>> >> >>>> Hello, >> >>>> I was following Christian's tutorial here: >> >>>> >> >>>> >> >>>> http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi >> >>>> >> >>>> And I also found come blog posts from JB that show how to deploy >> >>>> RESTful >> >>>> services using blueprint. >> >>>> >> >>>> What I couldn't find was an example on how to deploy a RESTful >> >>>> service >> >>>> where >> >>>> the resource class is an OSGi service (to take advantage of SCR >> >>>> references >> >>>> to other services in the resource class). I was able to do it by >> >>>> using a >> >>>> <reference> element instead of a <bean> element in the blueprint >> >>>> file. Is >> >>>> this approach correct or will it lead to other problems down the >> >>>> road? >> >>>> >> >>>> Thanks! >> >>>> Marc >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> View this message in context: >> >>>> >> >>>> http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html >> >>>> Sent from the Karaf - User mailing list archive at Nabble.com. >> >>> >> >>> >> >>> >> > > > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com
