JAX-RS RI for OSGi RFC-217

[Raymond Auge]

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

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 <[hidden email]> 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é (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

[Christian Schneider]

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 <[hidden email]>:

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 <[hidden email]> 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é (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

[Christian Schneider]

For reference here is an example that shows how to use Aries RSA and the CXF provider to export an annotated services as a REST resource:

https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-ds/service/src/main/java/net/lr/tasklist/service/TaskServiceRest.java

The CXF provider currently is not split into JAXWS and JAXRS but this should be done anyway to make each slimmer.

Christian

2016-05-12 18:51 GMT+02:00 Christian Schneider <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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é (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

[Raymond Auge]

Could you make your comments on the validity of the spec via the OSGi bugzilla?

I'm not really trying to debate the spec here just trying to find a home for an impl.

Sincerely,

- Ray

On Thu, May 12, 2016 at 12:54 PM, Christian Schneider <[hidden email]> wrote:

For reference here is an example that shows how to use Aries RSA and the CXF provider to export an annotated services as a REST resource:

https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-ds/service/src/main/java/net/lr/tasklist/service/TaskServiceRest.java

The CXF provider currently is not split into JAXWS and JAXRS but this should be done anyway to make each slimmer.

Christian

2016-05-12 18:51 GMT+02:00 Christian Schneider <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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é (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

[Raymond Auge]

One more point, the RFC proposes a whiteboard model rather than an extender model.

On Thu, May 12, 2016 at 1:43 PM, Raymond Auge <[hidden email]> wrote:

Could you make your comments on the validity of the spec via the OSGi bugzilla?

I'm not really trying to debate the spec here just trying to find a home for an impl.

Sincerely,

- Ray

On Thu, May 12, 2016 at 12:54 PM, Christian Schneider <[hidden email]> wrote:

For reference here is an example that shows how to use Aries RSA and the CXF provider to export an annotated services as a REST resource:

https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-ds/service/src/main/java/net/lr/tasklist/service/TaskServiceRest.java

The CXF provider currently is not split into JAXWS and JAXRS but this should be done anyway to make each slimmer.

Christian

2016-05-12 18:51 GMT+02:00 Christian Schneider <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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é (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

[Christian Schneider]

I agree. Will add my comments in the bugzilla. With whiteboard model you mean that the class must be exported as a service? That makes sense. 

On the other hand it is then already very similar to Remote Service Admin. 

In Aries RSA it is possible to create a custom ExportPolicy that would find services that contain a @Path annotation. It can then add the properties to export the service as a rest endpoint. So I can imagine that we could implement the new spec using Aries RSA.

If you prefer to create a separate project for the spec then I would not block this but I think it makes sense to consider simply adding this in Aries RSA. 

Christian

2016-05-12 21:32 GMT+02:00 Raymond Auge <[hidden email]>:

One more point, the RFC proposes a whiteboard model rather than an extender model.

On Thu, May 12, 2016 at 1:43 PM, Raymond Auge <[hidden email]> wrote:

Could you make your comments on the validity of the spec via the OSGi bugzilla?

I'm not really trying to debate the spec here just trying to find a home for an impl.

Sincerely,

- Ray

On Thu, May 12, 2016 at 12:54 PM, Christian Schneider <[hidden email]> wrote:

For reference here is an example that shows how to use Aries RSA and the CXF provider to export an annotated services as a REST resource:

https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-ds/service/src/main/java/net/lr/tasklist/service/TaskServiceRest.java

The CXF provider currently is not split into JAXWS and JAXRS but this should be done anyway to make each slimmer.

Christian

2016-05-12 18:51 GMT+02:00 Christian Schneider <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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é (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

[Raymond Auge]

I think the requirement is that one spec cannot require another spec (besides the core) in it's definition.

i.e. JAX-RS whiteboard should be implementable without RSA or DS for instance.

But as for the actual implementation, I think it should be fine if it leverages other spec. Like DS already does with CM for instance.

- Ray

On Thu, May 12, 2016 at 3:46 PM, Christian Schneider <[hidden email]> wrote:

I agree. Will add my comments in the bugzilla. With whiteboard model you mean that the class must be exported as a service? That makes sense. 

On the other hand it is then already very similar to Remote Service Admin. 

In Aries RSA it is possible to create a custom ExportPolicy that would find services that contain a @Path annotation. It can then add the properties to export the service as a rest endpoint. So I can imagine that we could implement the new spec using Aries RSA.

If you prefer to create a separate project for the spec then I would not block this but I think it makes sense to consider simply adding this in Aries RSA. 

Christian

2016-05-12 21:32 GMT+02:00 Raymond Auge <[hidden email]>:

One more point, the RFC proposes a whiteboard model rather than an extender model.

On Thu, May 12, 2016 at 1:43 PM, Raymond Auge <[hidden email]> wrote:

Could you make your comments on the validity of the spec via the OSGi bugzilla?

I'm not really trying to debate the spec here just trying to find a home for an impl.

Sincerely,

- Ray

On Thu, May 12, 2016 at 12:54 PM, Christian Schneider <[hidden email]> wrote:

For reference here is an example that shows how to use Aries RSA and the CXF provider to export an annotated services as a REST resource:

https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-ds/service/src/main/java/net/lr/tasklist/service/TaskServiceRest.java

The CXF provider currently is not split into JAXWS and JAXRS but this should be done anyway to make each slimmer.

Christian

2016-05-12 18:51 GMT+02:00 Christian Schneider <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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é (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

--