karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ward <tim.w...@paremus.com>
Subject Re: REST - Declarative Services
Date Wed, 30 May 2018 09:17:40 GMT
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 <slewis@composent.com> 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/
> 


Mime
View raw message