Bertrand Delacretaz wrote: > On Mon, Jun 15, 2009 at 3:18 PM, Carsten Ziegeler<[email protected]> wrote: >> Bertrand Delacretaz wrote: >>> 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. >>> >> What about merging this with Alex idea? >> We define properties for required bundles to be available and another >> one for the services. >> The sling main servlet (or some helper service) reads the props, >> and acts accordingly. This keeps everything in one single bundle and >> does not require any additional stuff. > > There's one additional requirement ;-) > > It should be easy for developers to augment this configuration when > installing additional services, without having to restart Sling. > > When adding a bundle that provides a Foo service, for example, I can > easily add a node under /system/sling/status, but modifying > sling.properties is harder, and less visible. > > We can still probably combine those ideas, maybe something like: > > sling.readyness.check = jcr:/system/sling/status > sling.readyness.check.1 = bundles:mybundleA, mybundleB > sling.readyness.check.2 = services:myServiceA, myServiceB > > in sling.properties. The SystemStatus service should then indicate, in > log messages, where it gets the actual list of things to check. > Hmm, not sure if I really understand this requirement :) You have a running system which is "ready". Then you install *additional* bundles and the system might be in the state "not ready" after adding additional stuff? Sounds a little bit strange to me.
Carsten -- Carsten Ziegeler [email protected]
