Hi,
Alexander Klimetschek schrieb:
> Hi all,
>
> when I update a bundle containing a servlet (eg. servlet path =
> /bin/myservlet) and I hit my curl command for testing that servlet
> (POST to /bin/myservlet + a few specific params) too fast, ie. in the
> time when the old version of the bundle is gone, but the new version
> is not yet started, and hence nothing is registered under
> /bin/myservlet, the request is handled by the SlingPostServlet, which
> in this case creates a new JCR node under /bin/myservlet.
>
> Any ideas how to circumvent this little annoyance during development?
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 ;-) ).
WDYT ?
Regards
Felix
