On Mon, Jun 15, 2009 at 4:05 PM, Carsten Ziegeler<cziege...@apache.org> wrote: > Bertrand Delacretaz wrote: >> On Mon, Jun 15, 2009 at 3:37 PM, Carsten Ziegeler<cziege...@apache.org> >> wrote: >>>> ... 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.... >> >> It's for the next startup - as I have added the Foo service, I want >> the system to wait for it to be ready on the next startup. >> > Hmm, but that's still strange - without a restart the check is not enforced > but with a restart it is? I think if this is the desired behaviour > changing the properties is appropriate.
The ideal case would be for the system to go from "ready" to "not ready" when you install an additional bundle, but that's harder to implement so I'd like to keep that for later, if needed. About properties vs. nodes...the initial content loading mechanism seems perfectly suited to add the require nodes when a bundle is installed, and remove them when it goes away (IIRC it does that), so that sounds like the simplest thing to do for user bundles. > ...On a different thing, OSGi is all about packages and services (bundles > are just the way of bundling them - more or less). As services are based > on interfaces and therefore packages, it should be enough to just check > for the availability of services.... Right, services should be enough. -Bertrand
