On Tue, Jun 16, 2009 at 2:44 PM, Felix Meschberger<fmesc...@gmail.com> wrote: > ...Well, *if* we want to check the system state, that check should be done > continuously during the whole lifetime otherwise it makes no sense, > honestly:...
As I said, SLING-490 is a first step that focuses to startup, and it's easy to add event-driven "reset/recompute the readyness state" features later on. The latter is not hard to implement (though certainly harder to test), but I'd like to do things in two phases to first get the basics right. > ...The goal is to not stop the system, so a system startup is a seldom case > and bruning cycles for a case, which almost never (in theory and as a > goal) happens, sounds not very productive.... My main use case is: -Start a Sling application embedded in a runnable jar. -Wait for Sling to be ready. -Open a browser on the applications's homepage. And not get a weird error on that page. It might be a demo use case, but failed demos are not a good way to convince people of Sling's coolness ;-) I agree that *in production webapps* the goal is to never restart but as the above shows that's not the only use case. And in practice we all know that restarts do happen, sometimes for reasons that have nothing to do with Sling, and getting weird errors because requests are accepted before the system is ready is ugly. -Bertrnad
