Hey Oli, Isnt that the whiteboard that I gave? https://github.com/apache/aries-jax-rs-whiteboard <https://github.com/apache/aries-jax-rs-whiteboard>
Greets Roy > On 28 Jan 2017, at 09:43, olimination <oliminat...@gmail.com> wrote: > > Hi Lance, > > as Mike already mentioned the "Neba framework" offers you the full > Spring power, meaning you can easily write Spring controllers which then > for example inject your needed OSGi services and you then do whatever > you need to do plus you have access to all the possibilities Spring > offers you. > > See doc here: http://neba.io/documentation.html#spring_mvc > > Or as far as I know with OSGi R7 there will be support for JAX-RS. > > See here: https://adapt.to/2016/en/schedule/osgi-r7.html > > cheers, > Oli > > On 28.01.2017 07:23, Henry Saginor wrote: >> Can’t you just create sling servlet registered to some resource type? >> You can then simply create JCR node(s) mapped to your resource type. >> You can also use a SynthaticResource via custom resource provider, which is >> the track you’re on and what Steven is suggesting. >> But I find that in most cases just creating a JCR node is more convenient >> and you can apply JCR ACLs to it control access if you need it. >> >>> On Jan 27, 2017, at 9:34 PM, Steven Walters <kemu...@gmail.com> wrote: >>> >>> On Sat, Jan 28, 2017 at 6:27 AM, lancedolan <lance.do...@gmail.com> wrote: >>>> Hi friends, >>>> >>>> I've tried routing questions through stackoverflow to cut down my mails to >>>> this list. I'm losing lots of time on this one, though, and am stuck. >>>> >>>> I need to create APIs which don't represent Sling Resources. Example: >>>> /services/images/123123123 >>>> that image will exist somewhere else. >>>> >>>> Bertrand suggests creating a ResourceProvider, as in the example here [1]. >>>> However, that uses the spi package which is not in version 2.9.0 of >>>> org.apache.sling.api, and thus, not available to me in Sling 8. >>>> >>>> I did find a ResourceProvider interface to implement though, and created >>>> this code: >>>> >>>> /** >>>> * Created by lancedolan on 1/27/17. >>>> */ >>>> @Component >>>> @Service(value=ResourceProvider.class) >>>> @Properties({ >>>> @Property(name = ResourceProvider.ROOTS, value = "things"), >>>> @Property(name = ResourceProvider.OWNS_ROOTS, value = "true") >>>> }) >>>> public class ImageResourceProvider implements ResourceProvider { >>>> >>>> /** If this provider required a context this would be more elaborate, >>>> * but for this simple example we don't need one. >>>> */ >>>> public static class DoesNotNeedAContext { >>>> }; >>>> >>>> @Override >>>> public Resource getResource(ResourceResolver resourceResolver, String >>>> path) { >>>> Resource returnResource = new SyntheticResource(resourceResolver, >>>> path, "edlio/microservice/image"); >>>> returnResource.getValueMap().put("myProp" , "myValue"); >>>> return returnResource; >>>> } >>>> >>>> @Override >>>> public Resource getResource(ResourceResolver resourceResolver, >>>> HttpServletRequest httpServletRequest, String path) { >>>> return getResource(resourceResolver , path); >>>> } >>>> >>>> @Override >>>> public Iterator<Resource> listChildren(Resource resource) { >>>> return null; >>>> } >>>> } >>>> >>>> >>>> The result is that I get a 403 response. How do I control the >>>> authentication >>>> for resources that don't actually exist? The fact that I'm not getting 404 >>>> means that my ResourceProvider is at least registering successfully. >>>> >>>> Finally, I'd much prefer to use Jersey if possible... Anybody have success >>>> getting Jersey to work in Sling 8? I dumped a bunch of time into it and >>>> gave >>>> up after class not found errors for classes that should be found [2]. >>>> >>>> The ultimate goal is just to provide a restful API in Sling 8 and the >>>> static-path-declaration of SlingSafeMethodsServlet just doesn't cut it. >>>> >>>> Thanks a million guys... >>> >>> The Sling paradigm for this is to create resources through the >>> resource provider, >>> and then create/register a servlet to respond to the resource type >>> you're creating (not a static path). >>> >>> So from your above code, you'd create an additional servlet registered >>> to the resourceType "edlio/microservice/image" (instead of registered >>> to a static path) and implement GET inside it. >>> >>> Without the corresponding servlet, this is most likely being served by >>> the default GET servlet, which will not particularly understand how to >>> deal with these resources, thus the errors. >> >>
