You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Mike Rose (JIRA)" <ji...@apache.org> on 2015/11/03 13:14:27 UTC

[jira] [Commented] (SLING-2192) Support JAX-RS resource classes

    [ https://issues.apache.org/jira/browse/SLING-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987169#comment-14987169 ] 

Mike Rose commented on SLING-2192:
----------------------------------

I recently did this myself for a project. Let's just say it is "non-trivial". I will share a few notes here based on my experience.

- I assembled a bundle that exports all the packages necessary to implement jax-rs 2.0 apis in any other bundles by importing the provided packages provided by my jax-rs bundle. This turned out to be a pretty good strategy. It kept the overall bundle bloat to a minimum and made implementing any number of bundles that each provided their own APIs fairly simple.

- One challenge that I had to overcome is that the Sling Models API / Impl bundles have a bit of sloppiness in their manifests and export the javax.annotation package without specifying any version constraints. This caused a conflict when trying to supply the newer versions of that package and its sub-packages required by Jersey and Jackson. In the end, I had to build my own custom versions of org.apache.sling.models.api and org.apache.sling.models.impl as well as build my own custom launchpad that replaced the default versions of those bundles in order workaround the package conflicts. (should I file an issue about cleaning that up?)

-  I really did not like the approach taken by Caravan JAX-RS Publisher and OSGi JAX-RS Connector. They want you to overload OSGi services and expose them as JAX-RS resources which seems to violate the "single purpose per component" and KISS principles. They also don't seem to allow you to group your resources together in a ResourceConfig, making it hard to keep related resources grouped into a common path in their URIs or register any custom Providers. Instead, I implemented this so that I could deploy my APIs as I would in any other container and inject other services (OSGi or otherwise) into my JAX-RS resource classes. I can easily inject a resource resolver and/or resources adapted to pojos with Jackson annotations in order to serve up any sort of content.

If anyone else thinks that they might find this useful I would be happy to share my implementation. Just drop me a line...

  

> Support JAX-RS resource classes
> -------------------------------
>
>                 Key: SLING-2192
>                 URL: https://issues.apache.org/jira/browse/SLING-2192
>             Project: Sling
>          Issue Type: New Feature
>            Reporter: Reto Gmür
>         Attachments: SLING-2192-20110310.patch, SLING-2192-20111004.patch, SLING-2192-20111013.patch, SLING-2192-new-jax-rs-bundle.patch, SLING-2192-new-jax-rs-bundle.patch, SLING-2192-with-sling-style-style-registration.patch, SLING-2192-with-tests.patch, jaxrs-in-contrib.patch, slingr-on-wink-osgi.patch
>
>
> It should be possible to register jax resource classes and providers as services. As they don't implement a specific interface services that expose java.lang.Object should be considered as javx-rs services iff they have the service property "javax.ws.rs" set to true.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)