On 11/4/2016 9:38 AM, Ancoron Luciferis wrote:
<stuff deleted>
Simply looking at the DOSGi architecture [1] (which just follows what
the specs demand) is an absolute overkill for the use case of simply
having a DS-annotated JAX-RS resource being exposed via HTTP service.
I assert that a full understanding of the RS/RSA architecture is largely
irrelevant to using RS/RSA for your and many other use cases. As an
alternative approach to understanding what's necessary, consider the
tutorial at [1].
I think that the approach taken by RS/RSA provides the necessary balance
between having a general and flexible architecture able to handle more
than a few use cases, but also providing a simple, well-integrated
api...(i.e. a Remote Service is just an OSGi service with some standard
service properties, and so can be used seemlessly with DS, any/all code
written for local services, etc).
Scott
[1]
http://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service
For the real distributed services case, it is a completely different
question. But that's worth a separate topic. ;)
Cheers,
Ancoron
Refs:
[1] http://cxf.apache.org/dosgi-architecture.html
Christian
2016-11-04 12:20 GMT+01:00 Ancoron Luciferis
<ancoron.lucife...@googlemail.com
<mailto:ancoron.lucife...@googlemail.com>>:
Hi,
I just went the DS-route myself with JAX-RS inside Karaf.
If you just want to publish a ReST endpoint going the remote services
route seems way too complex.
What I found very useful and reliable to work especially for the dynamic
resource service case is the following:
https://github.com/hstaudacher/osgi-jax-rs-connector
<https://github.com/hstaudacher/osgi-jax-rs-connector>
As a result, my JAX-RS resources are dynamically activated/deactivated
declarative service components including references to other services
(e.g. internal data services, validators, ...). DS takes care about the
life-cycle and the osgi-jax-rs-connector just creates/updates/deletes
the wiring to Jersey and the exposure via the HTTP service (still Jetty
in case of Karaf).
From a bundle-perspective, no direct wiring to the osgi-jax-rs-connector
is required as it detects the resources via annotation scanning (@Path).
Cheers,
Ancoron
On 04/11/16 09:38, Bram Pouwelse wrote:
> In case you're looking for a JAX-RS whiteboard implementation you could
> have a look at https://amdatu.org/application/web/
<https://amdatu.org/application/web/>. It doesn't implement
> the complete JAX-RS whiteboard draft spec. It does not have a
> JaxRSServiceRuntime implementation yet and it's currently using Apache
> Wink internally (which is a JAX-RS 1.0 implementation). But the
> whiteboard works as described in the JAX-RS whiteboard specification
draft.
>
> Next step for us will be replacing Wink by another JAX-RS implementation
> that does implement the JAX-RS 2.0 spec
>
> Regards,
> Bram
>
> On Fri, Nov 4, 2016 at 9:26 AM Tim Ward <tim.w...@paremus.com
<mailto:tim.w...@paremus.com>
> <mailto:tim.w...@paremus.com <mailto:tim.w...@paremus.com>>> wrote:
>
> I note that both of the Remote Services options provided have
> examples using JAX-RS annotated service interfaces, which doesn't
> actually match the code provided in the example below.
>
> Using Remote Services also doesn't give you a standard way to handle
> request scoped resources (i.e. prototype services) or a defined way
> to add JAX-RS filters, MessageBodyReaders etc. This is one of the
> reasons why a JAX-RS whiteboard specification is being created.
>
> A JAX-RS whiteboard also allows you to do things like returning a
> JAX-RS Response for streaming results, asynchronous returns, or just
> to give a response other than 200 without having to use an Exception
> in a main-line code path.
>
> Whilst it is therefore true that a subset of JAX-RS resources can be
> exposed using Remote Services, it's not necessarily a good option if
> you're looking to put together a full REST API.
>
> Regards,
>
> Tim
>
> Sent from my iPhone
>
> > On 4 Nov 2016, at 02:23, Scott Lewis <sle...@composent.com
<mailto:sle...@composent.com>
> <mailto:sle...@composent.com <mailto:sle...@composent.com>>>
wrote:
> >
> >> On 11/3/2016 2:17 AM, Christian Schneider wrote:
> >> You can use CXF-DOSGi to register your rest resource. You just
> need to add some properties to your example component to make
it work.
> >
> > Another option is to use ECF's impl of OSGI Remote Services [1]
> with the Jax-RS distribution provider [2,3]...which supports
either
> Jersey or CXF impls of Jax-RS.
> >
> > Scott
> >
> > [1]
>
http://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote_Services
<http://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote_Services>
> > [2]
>
http://wiki.eclipse.org/Distribution_Providers#Jax-RS_REST_Providers
<http://wiki.eclipse.org/Distribution_Providers#Jax-RS_REST_Providers>
> > [3] https://github.com/ECF/JaxRSProviders
<https://github.com/ECF/JaxRSProviders>
> >
> >
> >>
> >> See
> >> https://github.com/apache/cxf-dosgi/tree/master/samples
<https://github.com/apache/cxf-dosgi/tree/master/samples>
> >>
> >> There is a also a bndrun file to easily run and package
CXF-DOSGi
> for bndtools.
> >>
https://github.com/apache/cxf-dosgi/tree/master/samples/soap
<https://github.com/apache/cxf-dosgi/tree/master/samples/soap>
> >>
> >> Christian
> >>
> >>> On 03.11.2016 03:05, Tanvir wrote:
> >>> I have a REST resource class, say Employees, and I need access
> to another service using DS. Hence I have to make this call a
> component. Now objects instantiated by @component and JAX-RS
> Servlet are not same.
> >>>
> >>> I do not want to use static reference to the service as shown
> below. How this can be handled?
> >>>
> >>> -----------------------------------------------
> >>> @Component
> >>> @Path("employees")
> >>> public class EmployeeResource {
> >>> static MyService service;
> >>> @Reference
> >>> void setMyService(MyService s) {
> >>> service = s;
> >>> }
> >>>
> >>> @GET
> >>> @Produces("text/plain")
> >>> public String getEmployees() {
> >>> return service.get();
> >>> }
> >>> }
> >>>
> >>
> >>
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
<mailto:osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
<mailto:osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
