On Mon, Jun 15, 2009 at 1:42 PM, Carsten Ziegeler<cziege...@apache.org> wrote: > The stuff Alex suggests is similar to the idea we discussed some time > ago when we first thought about this. > If we use some kind of configuration for this check, the questions is > when is this configuration available? If first the engine starts, the > check is performed (with an empty or minimal configuration) you have > a system which is running, then at a later point the config kicks in > and your system is not ready anymore until the required stuff is running. > This might be nitpicking but the system might appear as ready although > its not....
I agree with you, that's not nitpicking. I did assume that a SlingRepository is required for Sling to operate - in which case the engine considers itself ready only if a SlingRepository is available *and* the status check succeeds. So the problem that you mention cannot happen. But this could be configurable, see below. > ...As a general note, checking if the system is ready might increase the > startup time as you're system is only responding if all required > services are really available. There might be cases where this is not > necessary.... Agreed, that's why we want to make this configurable. > ...let's add some other requirements :) The stuff must work without a > repository (again my use case for portlets do not have a repository)... How do you run Sling without a repository currently? The SlingAuthenticator fails if there's no repository, so do you use an alternate Authenticator? > ... and > it should work without third bundles like config admin etc.... Ok > ...Therefore a check like Alex suggest above which solely relies on the > OSGI API seems to be good start; the remaining question however is the > configuration therefore. > Now we could do this by requiring people to repackage the engine bundle > and adding a configuration as a resource to the bundle. The default > engine has zero checks. This would solve the provisioning of the config > but creates new problems when it comes to updates of the bundle etc.... This could also be configured by a property in sling.properties. For example: sling.readyness.check = jcr:/system/sling/status to indicate that the readyness check must use JCR nodes under that path to configure itself, like Alex suggests. Absence of that property means no readyness check, and we can later define prefixes other than "jcr" for alternate mechanisms, if needed. -Bertrand
