Hi, Am Donnerstag, den 29.05.2008, 13:29 +0200 schrieb Carsten Ziegeler: > This sounds good to me. I've one question, where do you configure the > path for the status servlet? At least the sling main servlet needs to > know this path. So why not making this an integral feature of the main > servlet?
We did not actually discuss this, but you are right, that colocating this functionality with the SlingMainServlet in one way or the other is probably a good idea. In addition, reading "Requests to /system/sling/status bypass this mechanism, of course." presents a question: Provided the status servlet is just another servlet registered with Sling, how would the SlingMainServlet be able to "bybass this mechanism". So probably the SlingMainServlet is itself directly triggering the script executions and thus handling requests to /system/sling/status internally. Regards Felix > > Carsten > > Bertrand Delacretaz wrote: > > Hi, > > > > We had a chat with Felix about a way to provide an URL that tells the > > outside world whether a Sling application is ready to run, after > > startup. I need this for an application that launches a Sling > > application, and opens the browser on its welcome page once the > > application is ready. > > > > The "ready to run" condition can be tricky to evaluate, as there's a > > lot of asynchronous stuff going on when starting a Sling application > > (which might include creating and initializing a JCR repository). > > > > The existing HttpTestBase.slingServerReady() method uses a simple > > mechanism that is good enough for integration testing, but not > > extensible and entirely defined on the client side. > > > > To provide a customizable readyness test, we suggest the following: > > > > 1) Create a SlingStatusServlet mapped to /system/sling/status > > > > 2) SlingStatusServlet depends on the JcrResourceResolverFactory, and > > returns an HTTP 503 status as long as that's not available. This is > > the minimal test of Sling readyness. > > > > 3) SlingStatusServlet looks for scripts in the repository, under > > /system/sling/status, which must only contain nodes that can be > > adapted to scripts > > > > 4) All scripts found there (finding none is acceptable) are executed, > > their output is concatenated in the servlet response, and if any of > > them throws an exception the status servlet returns a 503 error. > > > > 5) Before processing requests, the SlingMainServlet asks the > > SlingStatusServlet if it thinks the system is ready (based on the > > above dependencies + scripts), and if not throws a 503 error, > > indicating the reason. > > > > Requests to /system/sling/status bypass this mechanism, of course. > > > > Once the SlingStatusServlet returns true for this call, the > > SlingMainServlet does not make the call anymore. > > > > This should provide an easily extensible way of finding out whether > > Sling applications are completely initialized. > > > > WDYT? > > -Bertrand > > > >
