[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] JaxRS provider
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Thu, 20 Aug 2015 11:22:01 -0700
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
I've completed a first cut at an ECF Remote Services client provider
based upon JaxRS.
Specifically I ended up implementing using the jersey implementation in
Orbit, as libs and all dependencies have already been 'bundleized' and
exist in orbit, and it's a popular JaxRS implementation. The repo with
both bundles along with an initial example is here .
It's broken up into two bundles: 1)
org.eclipse.ecf.provider.jaxrs.client; and 2)
org.eclipse.ecf.provider.jersey.client. 1 only has dependencies on the
javax.ws.rs.* packages, which means it can be reused with *any* spec
compliant implementation of JaxRS. Most of the actual remote service
distribution provider code is here, although it's actually pretty
small. 2 is the jersey-specific implementation and essentially just
has code to configure Jersey (e.g. for supporting json, etc).
IMHO the cool thing about this provider is that it will/does work with
remote services exposed by non-jersey, non-osgi, even non-java
servers. It supports arbitrary arguments and return type serialization
via both xml and/or json.
Here's a simple example:
1) I setup an example running on tomcat (no OSGi) and exposing a xml and
rest-based service on tomcat.
2) I created a new service API bundle with
a) An interface: ISampleService  with the same jax-rs
(standardized) annotations as were present on the server resource
class. It doesn't have to be the same class as used on the server (or
even from the same package), it just needs to be an interface that has
the same class and method annotations.
b) A model class (or any model classes) used in 'a'. Here's the
The only dependencies in this service API bundle are to the
javax.ws.rs.* annotation types and to 'b'.
3) I created a simple consumer of the ISampleService  using a service
tracker calls a couple of the ISampleService remote service methods.
In this bundle I also created a EDEF file (to discover the
ISampleService remote service) called
helloserviceendpointdescription.xml . My intention is to create some
utilities to automate the creation of EDEF so that it's unnecessary to
Using the new ECF Endpoint Discovery view 
1) read the EDEF from 3, which discovers the ISampleService, creates the
remote service proxy (from the ISampleService class) and like any OSGi
service the proxy registration calls the test consumer's addingService
2) The addingService impl makes a couple of calls, which get turned into
http/https calls with java params serialized and injected into the url,
and the return value deserialized and returned as an instance of an
appropriate java object. All this happens/is implemented by the jersey
jax-rs impl, so that the call looks to the server just like any other
This is pretty cool, as it means that it's very very simple to take any
remote service that can be described by jax-rs annotations and turn it
into an OSGi remote service, with all the dynamics, API versioning
support, use of any OSGi service injection technology (spring, ds, dm,
etc., etc). And it will work the same way on any OSGi framework.
My intention is to create a wiki-based tutorial describing the above
once I get the chance, as well as create some more examples, and EDEF
utility code. Please let me know if you would like to
participate/contribute in this.
On 8/16/2015 11:21 AM, Scott Lewis wrote:
I wanted to let everyone know that I've implemented and started
testing two new ECF Remote Services distribution providers:
 One based upon Hazelcast 
 One based upon Jax REST Services . Since JaxRS is a
specification with multiple impls (e.g. resteasy, jersey, restlet,
etc) I have structured things so that a number of providers can/could
be created, and I've started testing one I've created based upon
The initial impls are done for both 1 and 2, and I'm working on test
and example code. If anyone would like to contribute/participate in
these impls, help with making them more useful, and/or create other
providers (e.g. based upon jersey, restlet, etc), please say so.
BTW, also update the no-OSGi ServiceRegistry examples  to use ECF
ecf-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit