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