Lgtm, +1 Carsten
2014-02-18 9:45 GMT+01:00 Felix Meschberger <fmesc...@adobe.com>: > Hi > > I have updated my whiteboard according to these suggestions: > > * Added new API to the Sling API (and increased export versions) > * Merged the parameter support back into the Engine bundle > * Removed the parameters bundle > > WDYT ? > > Regards > Felix > > Am 17.02.2014 um 16:19 schrieb Felix Meschberger <fmesc...@adobe.com>: > > > Hi > > > > You are right. > > > > And as we discussed off-line: Maybe we should make it really clean with > the > > > > List<NamedRequestParameter> getRequestParameterList() > > > > method and enance the API: > > > > RequestParameter: > > add String getName(); > > > > SlingHttpServletRequest: > > add List<RequestParameter> getRequestParameterList(); > > > > The drawback here is, that we add to the API with consequences for > implementors of this API, which I actually expect to only be the engine > bundle ... (others should just extend the SlingHttpServletRequestWrapper > class and be fine) > > > > WDYT ? > > > > Regards > > Felix > > > > Am 17.02.2014 um 16:14 schrieb Carsten Ziegeler <cziege...@apache.org>: > > > >> Hi, > >> > >> thanks - this looks good to me, especially as the performance impact > should > >> be neglectable. > >> I'm not sure if we really should split this into a separate bundle for > now > >> - we can do it later if the need arises. > >> > >> So basically +1 > >> > >> Carsten > >> > >> > >> 2014-02-17 10:35 GMT+01:00 Felix Meschberger <fmesc...@adobe.com>: > >> > >>> Hi all > >>> > >>> I have been working in my whiteboard extending Sling's request > parameter > >>> support with the following goals: > >>> > >>> 1. Support both Servlet API 2 and Servlet API 3 which brings > >>> multipart/form-data support with additional API. > >>> 2. Support Sling's request parameter support for non-Sling servlets. > >>> 3. Make sure request parameters are provided in the order they have > been > >>> stated in the request > >>> 4. Suppport an application requirement to get access to the request > >>> parameters in the order they have been defined on the request > >>> > >>> The third goal actually goes back to a Servlet API deficiency which > does > >>> not define this order. Unfortunately some of our application require > such > >>> an order and so we have to make sure. Also some servlet containers > (Jetty) > >>> support such a request parameter order by internally using a > LinkedHashMap > >>> while others (Tomcat) don't. With the new implementation of parsing the > >>> parameters we solve this difference and always provide a defined order. > >>> > >>> The implementation can be found at [1] > >>> > >>> BTW: The hack in the engine bundle using an ant compile step is to be > able > >>> to compile for both Servlet API 2 and Servlet API 3. If someone has a > >>> better, more elegant solution, I am more than happy to change the > current > >>> hack :-) > >>> > >>> WDYT ? > >>> > >>> Regards > >>> Felix > >>> > >>> [1] > http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/parameters > >> > >> > >> > >> > >> -- > >> Carsten Ziegeler > >> cziege...@apache.org > > > > -- Carsten Ziegeler cziege...@apache.org
