On 04/11/16 16:11, Christian Schneider wrote:
> Have you actually tried the examples from CXF-DOSGi 2.0.0?
No, but they look pretty simple. However, I have used CXF-DOSGi for a
distributed services setup some years ago.
>
> Are they really too complicated?
I didn't say nor meant 'complicated'. I said and I mean 'complex'. And
this is not from the simple example usage perspective. The complexity
here includes risks in the unknowns when you advocate this technology
but don't fully present all the little components that must work
together flawlessly to accomplish what the technology is being intended for.
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.
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
