Hi,
At first, I am very reluctant to this addition. One reason is that I
don't really think it is a good idea to call servlets for non-request
processing.
If we want to have background processing, we should define proper API
for starting background jobs and for providing feedback on job progress,
like error status, regular output etc.
If you still want to process such jobs through the SlingMainServlet, we
should define a proper API providing for providing input (real and
meta-parameters [is there a difference anyway ???]) and output. This
would be similar to the JSR-223 ScriptEngin interface ...
In the implementation we can still construct
[Sling]HttpServletRequest/Response objects to call the SlingMainServlet
internals.
This would
(a) reduce boiler plate (because not all users need to create
HttpServletRequest/Response objects)
(b) makes interaction clear
(c) allows for concise and clear documentation
(d) allows for decoupling
Regards
Felix
On 15.07.2010 09:52, Bertrand Delacretaz wrote:
> On Wed, Jul 14, 2010 at 6:54 PM, Alexander Klimetschek <[email protected]>
> wrote:
>> On Wed, Jul 14, 2010 at 18:02, Carsten Ziegeler <[email protected]> wrote:
>>> ...Why not creating plain http servlet request objects and then going
>>> through the sling main servlet?
>>
>> Interesting, how would you do that? I always thought the request
>> dispatcher is meant for this....
>
> I'll experiment today with adding the following interface to the Sling
> API and having the SlingMainServlet implement it:
>
> /** Process an HTTP request outside of the servlet container's
> * request/response cycle */
> public interface BackgroundRequestProcessor {
> void processRequest(HttpServletRequest req, HttpServletResponse res) {
> }
> }
>
> If that works for my SLING-550 use case, I'll post the resulting patch
> to JIRA before committing.
>
> -Bertrand
>
