I'm wondering what we really want to achieve here and if it is worth the effort? For production systems this is imho more a non-issue, as you usually don't update directly a productive machine.
For development you know that you updated a bundle and shouldn't send new requests during the update. Now, the problem is perhaps, that in some cases the update itself takes longer. This could be because of inefficient bundling, too many references etc. Just my 2cents :) Carsten Alexander Klimetschek wrote: > On Mon, Sep 1, 2008 at 11:02 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: >> This is of course also a possible scenario in a live environment, esp. >> in environments used globally: Imagine an IT department in USA updating >> the bundle while a user in Germany tries to use the service ... >> >> How about this approach: Based on the knowledge, that the >> SlingPostServlet is the default servlet for POST requests, we might : >> >> * Define a special operation in the SlingPostServlet, say "nop" (those >> of us remembering the old 6502 CPU might remember that ;-). >> * To be able to convey some expected "failure" status, we might add a >> parameter to this operation, say :nopstatus which conveys the status >> code to send back. >> * The :operation and :nopstatus (or generally all ":" prefixed >> parameters) are ignored by your POST servlet >> >> Now the client side of your POST servlet adds the following parameters: >> :operation=nop >> :nopstatus=503 >> >> If your POST servlet is active, the :operation and :nopstatus parameters >> are just ignored and everything runs smoothly. If your POST servlet is >> inactive, the SlingPostServlet is triggered, which sends back the 503 >> status as a result of executing the "nop" operation. >> >> This mechanism can even be used to verify the SlingPostServlet is active >> (provided no other POST servlet interferes ;-) ). > > Well, this is a solution, but this requires specifics of the > SlingPostServlet (the no-operation parameter) to be represented in my > client-side code, which I don't like. And it is not a generic solution > that solves the other issues mentioned in the thread (eg. jsp compile > issues) - or if some other default servlet gets triggered, depending > on the resource type and the servlet resolution. > > Regards, > Alex > -- Carsten Ziegeler [EMAIL PROTECTED]
