On Mon, Jun 15, 2009 at 3:25 PM, Bertrand Delacretaz<[email protected]> 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.
Why not use OSGi properties, as suggested? They are persisted, so after the next restart they will be applied (these settings only makes sense after restarts, right?), and people can choose whether they will use the OSGi config API, Felix webconsole or config nodes in the JCR to change the settings (in order of availability). Regards, Alex -- Alexander Klimetschek [email protected]
