On Tue, Aug 23, 2011 at 9:59 AM, Reto Bachmann-Gmür <[email protected]> wrote: > On Tue, Aug 23, 2011 at 2:56 PM, Carsten Ziegeler <[email protected]> > wrote: >> The servlet resolution is based on the resource resolution - and this >> means a path points at exactly one resource. This is nothing we should >> change! > I'm still not getting it. SlingServletResolver#getServlet iterates > through the different matching servlets. What are this different > candidates? Why is it OK to fall back to another kind of resource but > not to a lower priority OptingServlet? > >> Again, OptingServlet should be the exception to be used as it makes >> the servlet resolution much more complicated. You have to run the >> request to see which servlet is really used. Therefore this should be >> avoided whereever possible.We found out, that in most cases there are >> better option. > A better option for jax-rs resources would be to register a servlet > for every root-resource, for this the path matching in sling would > have to be as powerful as the one offered by jax-rs (i.e. support > regex). > >> For the case at hand, you could register a single servlet at that path >> - which is not an opting servlet and this one dispatches to the other >> servlets, one after the other, until one is processing this request. > > Not sure if I understand you correctly, are you suggesting to just > have a separate uri-space for jax-rs resources? (Clearly I would like > a tighter integration for sling to support scripts, Java Sevlets and > JAX-RS root resources at any path.)
Reto- Have you looked at integrating Wink at the HttpService layer, not with the Sling engine? It sounds like you want to avoid the Sling resource model in which case you'd probably be better served by operating at a level above the engine. I don't know about Wink, but I know that some JAX-RS implementations are available as Filters where if a JAX-RS resource matches the path, it is used, otherwise the request is handed off to the rest of the Filter Chain. This model works well for integrating with other webapps and I think would make sense in a Sling/OSGi context as well. I still think we should support multiple OptingServlets per resource type, but that's because I think it is intuitive (and I agree with Carsten that OptingServlet should be the exception, not the rule). Justin > > Regards, > Reto >
