Re: svn commit: r963686 - in /sling/trunk/contrib/extensions/bgservlets: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/sling/ src/main/java/org/apache/sling/bgservlets/ src/main/java/org/apache

[Bertrand Delacretaz <bd...@apache.org>]

Hi Justin,

On Tue, Jul 13, 2010 at 3:11 PM, Justin Edelson <ju...@gmail.com> wrote:
> ...This looks pretty cool. I like the idea of using the Servlet interface
> instead of Callable/Runnable....

Yes...it came out of a brainstorm session with my colleagues, I cannot
claim ownership of the idea ;-)

The main thing is allowing Joe Sling Programmer to create background
tasks easily.

>
> I have two comments:
>
> 1) The request/response pair passed to the servlet should be entirely
> synthetic. This is true in general AFAIK[1]; in Sling it is especially
> true because request.getResourceResolver() will return a closed resource
> resolver....

Yes, I already have some TODOs to look at that. It's probably not a
good idea to use request/response objects outside of the current
request's cycle. Right now I'm just hacking with minimal code, leaving
quite a few TODOs for such things.

>
> 2) Even with synthetic request/response objects, I suspect that not all
> servlets are going to work in the background (or s/going to/should/).
> Thus, what about using a marker interface on the servlet to declare that
> it should be run in the background. Or... to declare that it can be run
> in the background...

At present the class that decides to run the servlet in the background
is a Filter early in the chain, so it's not aware of which servlet is
used. Filtering servlets like you suggest might complicate things
quite a bit, and scripts cannot easily be marked like a servlet. What
would be simpler is to filter by path or path regexp, configurable in
that filter...or we can just assume for now that servlets will fail
loudly if unable to run in the background.

Thanks for the feedback!

-Bertrand