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 -- Alexander Klimetschek [EMAIL PROTECTED]
