[
https://issues.apache.org/jira/browse/SLING-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535166
]
Felix Meschberger commented on SLING-50:
> MimeTypeResolver: factor out the current SlingRequestContext.getMimeType()
> method
I think we should actually just drop the getMimeType() method and not introduce
a MimeTypeResolver in microsling because the API is available from the
ServletContext (getMimeType) and this method should also be used by microsling
and Sling servlets.
NB: In the real Sling, we might of course implement better MimeType resoultion
through the HttpContext we use to register the Sling Servlet with the OSGi
HttpService.
> microsling: complete the SlingRequestContext information
>
>
> Key: SLING-50
> URL: https://issues.apache.org/jira/browse/SLING-50
> Project: Sling
> Issue Type: Improvement
> Components: microsling
>Reporter: Bertrand Delacretaz
>
> Comparing microsling with the "full" Sling, the SlingRequestContext needs the
> following additional information:
> 1) ParsedRequestPath: extension, selectors, suffix, etc.
> 2) SlingRequestParameters: a wrapper for the HttpServletRequest parameters,
> that gives transparent access to parameters coming from multipart forms (at
> least in the full Sling, but the interface must be the same).
> 3) MimeTypeResolver: factor out the current SlingRequestContext.getMimeType()
> method
> The SlingRequestContext should as much as possible remain a container only,
> and delegate parsing and other tasks to separate classes
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.