You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/11/20 11:28:37 UTC

Servlet Resolution

Hi all,

I want to propose an extension to the current Servlet Resolution
process. At the moment Servlets in Sling (and microsling) are only
selected based on the Resource Type (Resource.getResourceType()) while
scripts are selected by resource type, selectors, HTTP request method
and response content type. The assumption is, that Servlets are complete
in a sense that they may implement different Java methods to support
different HTTP methods. How servlets support selectors and response
content types is completeley left to them.

This is a somewhat asymetric situation. So I propose to support the same
finer grained selection mechanisms for servlets: A servlet is registered
as an OSGi service with one or more service properties as follows:

   * sling.core.resourceTypes: A list of resource types supported by the
servlet. This
         is required for a Servlet service to be used for Sling.
   * sling.core.methods: A list of request methods supported by the
servlet. If the
         servlet is a SlingSafeMethodsServlet, the
getAllowedRequestMethods may be
         called to get this list if not set as a property. Otherwise any
request method
         is assumed to be supported.
   * sling.core.selectors: A list of regular expressions to match
against the selectors.
         If this property is missing, the servlet is assumed to support
any selectors.
   * sling.core.responsetype: A list of response types supported by the
servlet. Again,
         the servlet is assumed to support any response type, if the
property is missing.


WDYT ?

Regards
Felix