Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      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.

      Edit, December 2015: the discussions below suggest https://github.com/wcm-io-caravan/caravan-jaxrs as a good and Sling-friendly way of doing that.

      1. slingr-on-wink-osgi.patch
        49 kB
        Reto Gmür
      2. jaxrs-in-contrib.patch
        58 kB
        Reto Gmür
      3. SLING-2192-20111013.patch
        53 kB
        Reto Gmür
      4. SLING-2192-20111004.patch
        55 kB
        Reto Gmür
      5. SLING-2192-20110310.patch
        55 kB
        Reto Gmür
      6. SLING-2192-with-tests.patch
        50 kB
        Bertrand Delacretaz
      7. SLING-2192-with-sling-style-style-registration.patch
        45 kB
        Reto Gmür
      8. SLING-2192-new-jax-rs-bundle.patch
        16 kB
        Reto Gmür
      9. SLING-2192-new-jax-rs-bundle.patch
        9 kB
        Reto Gmür

        Activity

        Hide
        Bertrand Delacretaz added a comment -

        Thanks Stefan Seifert, as https://github.com/wcm-io-caravan/caravan-jaxrs seems to work fine in Sling we might just recommend this to users who want to use JAX-RS.

        Show
        Bertrand Delacretaz added a comment - Thanks Stefan Seifert , as https://github.com/wcm-io-caravan/caravan-jaxrs seems to work fine in Sling we might just recommend this to users who want to use JAX-RS.
        Hide
        Mike Rose added a comment - - edited

        I had been working off of trunk/master for a while and have been working off of launchpad 8 since it was released. Launchpad 8 depends on v 1.2.2 of the Sling Models api/impl. Here are the relevant excerpts from the manifest of Sling Model api:

        Import-Package:
            --------> javax.annotation,javax.inject <--------
        
        Export-Package:
            org.apache.sling.models.annotations;version="1.2.0";uses:="javax.inject",
            org.apache.sling.models.annotations.injectorspecific;version="1.1.0";uses:="org.apache.sling.models.annotations,org.apache.sling.models.spi.injectorspecific".
            --------> org.apache.sling.models.factory;version="1.1.0";uses:="javax.annotation",  <--------
            org.apache.sling.models.spi;version="1.1.1";uses:="javax.annotation,org.apache.sling.models.factory",
            org.apache.sling.models.spi.injectorspecific;version="1.1.1";uses:="org.apache.sling.models.annotations.injectorspecific"
        
        

        I added the following import to the Maven Bundle Plugin configuration in Sling Models api to resolve this:

            <Import-Package>
                javax.annotation;version="[0,1)"
            </Import-Package>
        

        This directs this bundle to only try to import (and then in turn export) only the version of the javax.annotation package supplied with the Felix OSGi Framework bundles. Then I could supply the 1.2 version of that package from my JAX-RS enabling bundle without conflict.

        I will freely admit that I am new to both Sling and OSGi and could be misinterpreting what I have observed and may be going about resolving this entirely the wrong way. I will gladly accept any insight or advice you can offer.

        Show
        Mike Rose added a comment - - edited I had been working off of trunk/master for a while and have been working off of launchpad 8 since it was released. Launchpad 8 depends on v 1.2.2 of the Sling Models api/impl. Here are the relevant excerpts from the manifest of Sling Model api: Import-Package: --------> javax.annotation,javax.inject <-------- Export-Package: org.apache.sling.models.annotations;version="1.2.0";uses:="javax.inject", org.apache.sling.models.annotations.injectorspecific;version="1.1.0";uses:="org.apache.sling.models.annotations,org.apache.sling.models.spi.injectorspecific". --------> org.apache.sling.models.factory;version="1.1.0";uses:="javax.annotation", <-------- org.apache.sling.models.spi;version="1.1.1";uses:="javax.annotation,org.apache.sling.models.factory", org.apache.sling.models.spi.injectorspecific;version="1.1.1";uses:="org.apache.sling.models.annotations.injectorspecific" I added the following import to the Maven Bundle Plugin configuration in Sling Models api to resolve this: <Import-Package> javax.annotation;version= "[0,1)" </Import-Package> This directs this bundle to only try to import (and then in turn export) only the version of the javax.annotation package supplied with the Felix OSGi Framework bundles. Then I could supply the 1.2 version of that package from my JAX-RS enabling bundle without conflict. I will freely admit that I am new to both Sling and OSGi and could be misinterpreting what I have observed and may be going about resolving this entirely the wrong way. I will gladly accept any insight or advice you can offer.
        Hide
        Stefan Seifert added a comment -

        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

        which version of sling models did you use? this should be fixed with SLING-4710 / sling models API 1.2.0.

        Show
        Stefan Seifert added a comment - 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 which version of sling models did you use? this should be fixed with SLING-4710 / sling models API 1.2.0.
        Hide
        Mike Rose added a comment -

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

        Show
        Mike Rose added a comment - 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...
        Hide
        Stefan Seifert added a comment -

        if your are looking for a "make JAX-RS compatible with OSGI" solution which can run nicely in a sling launchpad and OSGi but beside this is not integrated further with Sling have a look at this:
        http://caravan.wcm.io/jaxrs/publisher/
        it supports registering OSGi services as JAX-RS components with all OSGi features like dependency injection and services coming and going, and ensures that for every bundle an own JAX-RS application is instantiated so different bundles containing JAX-RS services in the same container do not conflict with each other. it's based on jersey.
        in the github repo you'll find an integration test example as well.

        there are alternative JAX-RS OSGi integrations listed on the mentioned page as well, esp. the OSGi JAX-RS Connector is well-maintained, but it has some problems like merging all services from all bundles into one single JAX-RS application.

        Show
        Stefan Seifert added a comment - if your are looking for a "make JAX-RS compatible with OSGI" solution which can run nicely in a sling launchpad and OSGi but beside this is not integrated further with Sling have a look at this: http://caravan.wcm.io/jaxrs/publisher/ it supports registering OSGi services as JAX-RS components with all OSGi features like dependency injection and services coming and going, and ensures that for every bundle an own JAX-RS application is instantiated so different bundles containing JAX-RS services in the same container do not conflict with each other. it's based on jersey . in the github repo you'll find an integration test example as well. there are alternative JAX-RS OSGi integrations listed on the mentioned page as well, esp. the OSGi JAX-RS Connector is well-maintained, but it has some problems like merging all services from all bundles into one single JAX-RS application.
        Hide
        Alexander Klimetschek added a comment - - edited

        Generally speaking: Sling has its own concept of approaching REST, by means of addressing Resources first and the ResourceResolver framework for that. JAX-RS is inherently incompatible with that - you can make it live side by side next to Sling, via registration on the OSGI HTTP Service, but that's it.

        The above questions are really about "make JAX-RS compatible with OSGI" (which it is currently not, since its registration model is wire once, it does not take services coming and going into account, and as Clint mentions, bundle modularization is difficult). I don't think Sling itself should worry about this. If users run JAX-RS stuff next to Sling on the same JVM/OSGI container (and all the questions are solved), fine, but that is outside the scope of the Sling framework.

        It's good that the OSGi Alliance itself is looking into that. Just one note: the RFP-173 draft talks about "RESTful" in the first sentence. However, the person who defined the term REST, says that JAX-RS is anything but REST, so I think it would be nice for the OSGi alliance to avoid that term in their integration work of JAX-RS.

        Show
        Alexander Klimetschek added a comment - - edited Generally speaking: Sling has its own concept of approaching REST, by means of addressing Resources first and the ResourceResolver framework for that. JAX-RS is inherently incompatible with that - you can make it live side by side next to Sling, via registration on the OSGI HTTP Service, but that's it. The above questions are really about "make JAX-RS compatible with OSGI" (which it is currently not, since its registration model is wire once, it does not take services coming and going into account, and as Clint mentions, bundle modularization is difficult). I don't think Sling itself should worry about this. If users run JAX-RS stuff next to Sling on the same JVM/OSGI container (and all the questions are solved), fine, but that is outside the scope of the Sling framework. It's good that the OSGi Alliance itself is looking into that. Just one note: the RFP-173 draft talks about "RESTful" in the first sentence. However, the person who defined the term REST, says that JAX-RS is anything but REST , so I think it would be nice for the OSGi alliance to avoid that term in their integration work of JAX-RS.
        Hide
        Carsten Ziegeler added a comment -

        I think we should look at what the OSGi Alliance is probably starting to specify soon:
        https://github.com/osgi/design/blob/master/rfps/rfp-0173-JAX-RS-Services.pdf

        Show
        Carsten Ziegeler added a comment - I think we should look at what the OSGi Alliance is probably starting to specify soon: https://github.com/osgi/design/blob/master/rfps/rfp-0173-JAX-RS-Services.pdf
        Show
        Clinton H Goudie-Nice added a comment - cc: Carsten Ziegeler Bertrand Delacretaz
        Hide
        Clinton H Goudie-Nice added a comment - - edited

        As I've been looking at this patch, I've been thinking of a few problems.

        1) The @Service(Object.class) and @Property(name="javax.ws.rs", boolValue=true)
        IMO, this feels a bit of a hack.

        2) The shared container provides some potentially undesirable behavior.

        If I have two different bundles, each providing some Resources and each providing some Providers, one bundle's providers can be used by another bundle. For example, I have two resources that produce text/html, bundle A provides a MessageBodyWriter for text/html, and bundle B does not. Is it intentional that bundle B can use the writer from bundle A if bundle A is started and active? Should bundle B provide it's own implementation? What happens if they both provide writers for text/html.

        If two bundles have overlapping Resources, what would the intended behavior be? I can't clearly figure it out.

        If bundle A provides an exception mapper, say for a resource not found, and it is evaluated first, would it fall through to bundle B? Should it?

        3) Adding the @Service annotation indicates a singleton class, but this is contrary to JaxRS, where a resource is only a singleton if it's annotated with @Singleton

        Additionally, I don't see support for a non-singleton class.

        4) I'm not a big fan of the servlet listening on any specific URI. I think it is indicative of non-sling like behavior, and results in difficulty figuring out who is handling which URIs. If my bundle listens on /, provides an exception mapper for resource not found, who's resource mapper is more important? Mine or slings?

        As I've been thinking about the problem space, I've been thinking of a solution that looks like this:
        A) A specific sling node, in the tree, that defines all attributes of a jax-rs container. This includes, a list of resources, providers, exception mappers, features, etc..
        B) The jaxrs container is life-cycled with the bundle that it refers to, so if that bundle is offline, so is the container.
        C) The sling uri to the container is the root context of the bridge between sling and jaxrs.

        This resolves (1) as the resources, providers, etc are explicitly defined in the sling node.
        This resolves (2) as each container is isolated from each other container.
        This resolves (3) as the container itself builds the classes referred to and can maintain it's own isolation and lifecycle.
        This resolves (4) as you must define a sling path to a given set of resources. From there the tree to the individual resources is obscured, but the root context is not obscured.

        Thoughts?

        Show
        Clinton H Goudie-Nice added a comment - - edited As I've been looking at this patch, I've been thinking of a few problems. 1) The @Service(Object.class) and @Property(name="javax.ws.rs", boolValue=true) IMO, this feels a bit of a hack. 2) The shared container provides some potentially undesirable behavior. If I have two different bundles, each providing some Resources and each providing some Providers, one bundle's providers can be used by another bundle. For example, I have two resources that produce text/html, bundle A provides a MessageBodyWriter for text/html, and bundle B does not. Is it intentional that bundle B can use the writer from bundle A if bundle A is started and active? Should bundle B provide it's own implementation? What happens if they both provide writers for text/html. If two bundles have overlapping Resources, what would the intended behavior be? I can't clearly figure it out. If bundle A provides an exception mapper, say for a resource not found, and it is evaluated first, would it fall through to bundle B? Should it? 3) Adding the @Service annotation indicates a singleton class, but this is contrary to JaxRS, where a resource is only a singleton if it's annotated with @Singleton Additionally, I don't see support for a non-singleton class. 4) I'm not a big fan of the servlet listening on any specific URI. I think it is indicative of non-sling like behavior, and results in difficulty figuring out who is handling which URIs. If my bundle listens on /, provides an exception mapper for resource not found, who's resource mapper is more important? Mine or slings? As I've been thinking about the problem space, I've been thinking of a solution that looks like this: A) A specific sling node, in the tree, that defines all attributes of a jax-rs container. This includes, a list of resources, providers, exception mappers, features, etc.. B) The jaxrs container is life-cycled with the bundle that it refers to, so if that bundle is offline, so is the container. C) The sling uri to the container is the root context of the bridge between sling and jaxrs. This resolves (1) as the resources, providers, etc are explicitly defined in the sling node. This resolves (2) as each container is isolated from each other container. This resolves (3) as the container itself builds the classes referred to and can maintain it's own isolation and lifecycle. This resolves (4) as you must define a sling path to a given set of resources. From there the tree to the individual resources is obscured, but the root context is not obscured. Thoughts?
        Hide
        Krystian Panek added a comment -

        +1

        Show
        Krystian Panek added a comment - +1
        Hide
        Roy Teeuwen added a comment -

        Could anyone tell me what ever happend with this? No support yet for jax-rs?

        Show
        Roy Teeuwen added a comment - Could anyone tell me what ever happend with this? No support yet for jax-rs?
        Hide
        Reto Gmür added a comment -

        This patch uses the newly release wink-osgi bundle. The created bulde is thus much smaller but to run it requires additionally the wink-osgi bundle.

        Show
        Reto Gmür added a comment - This patch uses the newly release wink-osgi bundle. The created bulde is thus much smaller but to run it requires additionally the wink-osgi bundle.
        Hide
        Reto Gmür added a comment -

        Finally a patch to add the jaxrs in contrib, also contains some version updates in the testing pom.

        Show
        Reto Gmür added a comment - Finally a patch to add the jaxrs in contrib, also contains some version updates in the testing pom.
        Hide
        Reto Gmür added a comment -

        SLING-2192-20111013.patch includes the tests and other requested improvements but it it not yet moved to contrib

        Show
        Reto Gmür added a comment - SLING-2192 -20111013.patch includes the tests and other requested improvements but it it not yet moved to contrib
        Hide
        Bertrand Delacretaz added a comment -

        Agreed, so that would be contrib/extensions/jaxrs, with integration tests under contrib/launchpad/testing

        Show
        Bertrand Delacretaz added a comment - Agreed, so that would be contrib/extensions/jaxrs, with integration tests under contrib/launchpad/testing
        Hide
        Carsten Ziegeler added a comment -

        The new bundle should go under /contrib (not /bundles) first.

        Show
        Carsten Ziegeler added a comment - The new bundle should go under /contrib (not /bundles) first.
        Hide
        Bertrand Delacretaz added a comment -

        Thanks for the updated patch, I still have a few comments:

        1) Are the RequestUriOptingServlet2Test.java and RequestUriOptingServlet2 tests useful with your latest patch? IIUC you switched to servlet filters so they're probably not needed, or should be part of a separate issue.

        2) The SimpleRootResourceTest of my SLING-2192-with-tests patch is missing

        3) The new bundle should be at bundles/extensions/jaxrs like in that patch

        4) I think we don't need the samples/slingrs, we'll create integration tests instead, that also act as code samples

        Show
        Bertrand Delacretaz added a comment - Thanks for the updated patch, I still have a few comments: 1) Are the RequestUriOptingServlet2Test.java and RequestUriOptingServlet2 tests useful with your latest patch? IIUC you switched to servlet filters so they're probably not needed, or should be part of a separate issue. 2) The SimpleRootResourceTest of my SLING-2192 -with-tests patch is missing 3) The new bundle should be at bundles/extensions/jaxrs like in that patch 4) I think we don't need the samples/slingrs, we'll create integration tests instead, that also act as code samples
        Hide
        Reto Gmür added a comment -

        With the previous patch registered a default wink resource for / was registered which conflicted with WebDav.

        Show
        Reto Gmür added a comment - With the previous patch registered a default wink resource for / was registered which conflicted with WebDav.
        Hide
        Reto Gmür added a comment -

        The timing issue aou mention under 3 is the motivation for SLING-2191, this is no longer an issue as the latest patch uses Servlet-Filter instead of OptingServlets.

        Show
        Reto Gmür added a comment - The timing issue aou mention under 3 is the motivation for SLING-2191 , this is no longer an issue as the latest patch uses Servlet-Filter instead of OptingServlets.
        Hide
        Reto Gmür added a comment -

        This patch incorporates the review comments 1 to 3. No new test is added as I wasn't sure against which resource type to register and test.

        Show
        Reto Gmür added a comment - This patch incorporates the review comments 1 to 3. No new test is added as I wasn't sure against which resource type to register and test.
        Hide
        Reto Gmür added a comment -

        Thanks for your review!

        In the patch for WINK-351 unregistration of resources is implemented. I will integrate this into a patch for this issue.

        There is currently a big code duplications between this issue and WINK-351, the idea of WINK-351 is to put the part that can be used both in Sling and Clerezza into wink. If the patch gets accepted for wink a future implementation of this feature in sling will require much less code.

        Show
        Reto Gmür added a comment - Thanks for your review! In the patch for WINK-351 unregistration of resources is implemented. I will integrate this into a patch for this issue. There is currently a big code duplications between this issue and WINK-351 , the idea of WINK-351 is to put the part that can be used both in Sling and Clerezza into wink. If the patch gets accepted for wink a future implementation of this feature in sling will require much less code.
        Hide
        Bertrand Delacretaz added a comment -

        Thanks for your contribution!

        Looks interesting, I tested it and made a few changes to your patch:
        -Moved bundle under extensions
        -Added the examples to the test-services instead of a separate sample so that they run as part of the build time integration tests.
        -Added an integration test, SimpleRootResourceTest

        I saw three issues in my tests:

        1) It seems like resources are not unregistered if you change their path: start with path A, install the bundle, change to path B in source code, install bundle, both A and B paths are active.

        2) More logging would be useful, in the SlingRSRegistrar and related classes.

        3) There seems to be an initialization timing issue, if starting a Sling instance with both jaxrs and test-services bundles installed sometimes the SimpleRootResource is not available. It becomes available after reinstalling the test-services bundle, so I assume the service detection is fragile w.r.t. installation/startup timing.

        Could you add more similar integration tests, including one with a resource that's registered by resource type? We want to discourage path-based registration in general.

        See launchpad/integration-tests/README.txt for how to run the integration tests individually agains a previously started instance, as they can take a few minutes when run in a full build.

        Show
        Bertrand Delacretaz added a comment - Thanks for your contribution! Looks interesting, I tested it and made a few changes to your patch: -Moved bundle under extensions -Added the examples to the test-services instead of a separate sample so that they run as part of the build time integration tests. -Added an integration test, SimpleRootResourceTest I saw three issues in my tests: 1) It seems like resources are not unregistered if you change their path: start with path A, install the bundle, change to path B in source code, install bundle, both A and B paths are active. 2) More logging would be useful, in the SlingRSRegistrar and related classes. 3) There seems to be an initialization timing issue, if starting a Sling instance with both jaxrs and test-services bundles installed sometimes the SimpleRootResource is not available. It becomes available after reinstalling the test-services bundle, so I assume the service detection is fragile w.r.t. installation/startup timing. Could you add more similar integration tests, including one with a resource that's registered by resource type? We want to discourage path-based registration in general. See launchpad/integration-tests/README.txt for how to run the integration tests individually agains a previously started instance, as they can take a few minutes when run in a full build.
        Hide
        Reto Gmür added a comment -

        Added a patch that adds support to "slingrs": jax-rs style resources that use jax-features such argument injection and response processor. path contain implementation and demo bundle.

        Resources classes with the property sling.ws.rs set to true are bound the sling way with the same annotations as the equivalent servlet. In the thread at http://mail-archives.apache.org/mod_mbox/sling-dev/201108.mbox/%3CCAEWfVJ=TwX1cNoNpSCQ198vYfyspaTKwy_v9Ufxj4Nq=Ff70MQ@mail.gmail.com%3E supporting jax-rs has been seen as concurring with the sling way of doing things, this patch shows how one can have sling-style binding and jax-rs features that make writing application easier.

        Show
        Reto Gmür added a comment - Added a patch that adds support to "slingrs": jax-rs style resources that use jax-features such argument injection and response processor. path contain implementation and demo bundle. Resources classes with the property sling.ws.rs set to true are bound the sling way with the same annotations as the equivalent servlet. In the thread at http://mail-archives.apache.org/mod_mbox/sling-dev/201108.mbox/%3CCAEWfVJ=TwX1cNoNpSCQ198vYfyspaTKwy_v9Ufxj4Nq=Ff70MQ@mail.gmail.com%3E supporting jax-rs has been seen as concurring with the sling way of doing things, this patch shows how one can have sling-style binding and jax-rs features that make writing application easier.
        Hide
        Reto Gmür added a comment -

        added missing files. Thanks Bertrand.

        Show
        Reto Gmür added a comment - added missing files. Thanks Bertrand.
        Hide
        Bertrand Delacretaz added a comment -

        Note that the pom.xml is missing from your patch. I'll also discuss the JaxRsServlet servlet registration on the dev list.

        Show
        Bertrand Delacretaz added a comment - Note that the pom.xml is missing from your patch. I'll also discuss the JaxRsServlet servlet registration on the dev list.
        Hide
        Reto Gmür added a comment -

        new bundle adding jax-rs resources support using apache wink.
        Missing:

        • Tests (need resoution of SLING-2191)
        • unregistrations of components/providers
        Show
        Reto Gmür added a comment - new bundle adding jax-rs resources support using apache wink. Missing: Tests (need resoution of SLING-2191 ) unregistrations of components/providers

          People

          • Assignee:
            Unassigned
            Reporter:
            Reto Gmür
          • Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated:

              Development