Almost certainly the simplest option has already been suggested. The OSGi JAX-RS whiteboard provides a simple, standard mechanism for registering JAX-RS applications, resources, and extensions using the OSGi service registry. The Aries JAX-RS whiteboard is the Reference Implementation of this spec, and is in the process of being released (it should be available within the next three weeks). Using the JAX-RS whiteboard gives you more control over your resources, gives you access to more of the JAX-RS specification, and is more portable than using RSA.
There’s a simple set of tutorials using the R7 specifications provided by OSGi enRoute: https://enroute.osgi.org/Tutorial/ <https://enroute.osgi.org/Tutorial/> The quickstart application should provide you with everything you need. Best Regards, Tim > On 29 May 2018, at 17:03, Scott Lewis <[email protected]> wrote: > > On 5/28/2018 10:40 AM, Guenther Schmidt wrote: >> Hello All, >> >> I’ve been developing services using Declarative Services for dependency >> injection and it was a breeze so far. Now I want to expose some of the >> functionality via a REST API and I’m stuck. So far I’ve deployed my bundles >> through bundle:install -s man: …. all very easy. But what should be simple, >> exposing this through REST is becoming difficult. There are tips out there >> suggesting to use Blueprint, which I don’t want, others seem to suggest that >> I need to create a “feature” package. >> >> Then there’s also the requirements to “feature” install cxf. That’s OK btw, >> I only have to do that once. But is there really no simple way to create a >> simple REST service using merely DS? >> >> Guenther >> >> > Hi Guenther, > > Another option would be ECF Remote Services [1]. It's a full implementation > of the OSGi Remote Services and Remote Service Admin (R7/latest) > specifications [2]. These specifications standardize the remoting of OSGi > services (meta-data and dynamics), so it works seemlessly with DS and other > frameworks that use the OSGi service registry. > > ECF has a provider architecture so allows the use of a variety of > distribution providers [3], including CXF [4]. > > We have features defined for Karaf [5] and we also now have support for > bndtools-based development [6] (workspace and project templates). > > Caveat: ECF is in the middle of 'release season' for the Eclipse > simultaneous release (late June), so the transition to ECF 3.14.0 is not yet > complete. For example, the Karaf features don't yet point to 3.14.0 at maven > central only because we have to wait for the SR process before deployment of > the release to maven central. However, I'm happy to provide needed support > via [7]. > > Scott > > [1] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project > > [2] > https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteserviceadmin.html > > [3] https://wiki.eclipse.org/Distribution_Providers > > [4] https://github.com/ECF/JaxRSProviders > > [5] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf > > [6] https://wiki.eclipse.org/Bndtools_Support_for_Remote_Services_Development > > [7] https://accounts.eclipse.org/mailing-list/ecf-dev > > [8] http://eclipseecf.blogspot.com/ >
