Hi, On 20.07.2010 21:24, Alexander Klimetschek wrote: > On Tue, Jul 20, 2010 at 18:17, Carsten Ziegeler <[email protected]> wrote: >> Am 20.07.10 15:20, schrieb Felix Meschberger: >>> >>> Maybe a request/response-builder is better: >>> >>> SlingHttpServletRequest = new SlingHttpServletRequestBuilder( >>> resolver) >>> .addAttribute(name,value) >>> .addParameter(name,value) >>> .setMethod(name) >>> .setPath(path) >>> .toSlingHttpServletRequest(); >>> >>> Provided some useful defaults (like request method and path) and >>> constructor arguments (e.g. HttpServletRequest for the "default" use >>> case). This might be more flexible and easier to use. >>> >>> A corresponding SlingHttpServletResponseBuilder would do the same for >>> responses. >>> >> I think if we introduce some request processing interface on one way or >> the other, we don't need these factories. The interface should use plain >> http servlet request/response and not the Sling versions. And those >> objects can be created in any way. >> >> Using the servlet request / response interfaces makes integration this >> service easier as the calling client might already have such objects. > > I would agree. I think it is the job of the sling main servlet to > create the SlingHttpServlet* objects based on plain HttpServlet* ones.
Please reconsider the use cases for the basic thing we want to build: A processor taking request/response objects to be run (a) for regular HTTP requests and (b) for batched/long-running/background/whatever requests without a real HTTP request behind. For case (a) we have a HttpServletRequest/Response combo ready for use. For case (b) we don't generally have one (or we have one to use as the basis but not for direct use, because the objects will be unusable once the real request has terminated). So we have to have functionality to (a) create SlingHttpServletRequest/Response objects out of regular HTTP objects and (b) create SlingHttpSeervletRequest/Response objects "out of nothing". For (a) we can of course reuse the real HTTP request/response objects for (b) we can't. Thus by defining two simple builders to setup a SlingHttpServeltRequest/Response object which is at the heart of all Sling processing, we can handle both cases transparently without special casing again. Please remember my other proposal: Separate SlingMainServlet functionality from the SlingServlet service implementation. The SlingServlet.process method will take SlingHttpServletRequest/Response objects, which can (but are not required to be) built with the builder helpers. Regards Felix > > Regards, > Alex >
