If I understood this correctly then the whiteboard extender would pick up
all classes annotated with @Path. I dont think this is a good approach.
Such an extender would always compete with a DI framework like blueprint or
DS.

A much better approach is used by Remote Service Admin. It picks up only
jaxrs endpoints that are exposed as OSGi services. This has the big benefit
that the DI framework creates the instance and does the service injections.

Is there a good reason to publish JAXRS classes that are no OSGi services?
Maybe the spec could be changed to simply explain how to expose Rest
resources in Remote Service Admin in a standardized way.

The CXF provider for Aries RSA already can expose annotated OSGi services
as JAXRS Endpoints.
If you want a slimmer implementation than CXF then I propose we create an
additional provider for Aries RSA. It should not be difficult to extend
your code to make it a RSA provider.

Christian

2016-05-12 18:09 GMT+02:00 Raymond Auge <raymond.a...@liferay.com>:

> Oh, here is a link to the current implementation bundles:
>
>
> https://github.com/liferay/liferay-portal/tree/master/modules/apps/foundation/portal-remote
>
> - Ray
>
> On Thu, May 12, 2016 at 12:00 PM, Raymond Auge <raymond.a...@liferay.com>
> wrote:
>
>> Hello all,
>>
>> Some of you may be aware of the R7 work toward a spec for JAX-RS
>> Whitaboard [1].
>>
>> There's some interest in developing an RI based on some open source work
>> by Liferay starting from it's existing JAX-RS whiteboard implementation
>> (which is already relatively close to the current RFC). The implementation
>> is currently a thin wrapper around a minimal Apache CXF.
>>
>> To this end we're wondering if the Aries project would be interested it
>> accepting:
>> 1) a donation of code to bootstrap this work
>> 2) a new committer to help drive the effort toward full support of the
>> spec and further maintenance (Carlos Sierra [2] whom I'm encouraging to
>> join Aries lists and familiarize himself with Apache process)
>>
>> Please let me know.
>>
>> [1] https://github.com/osgi/design/tree/master/rfcs/rfc0217
>> [2] https://github.com/csierra/
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>  (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>> (@OSGiAlliance)
>>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>



-- 
-- 
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>

Reply via email to