Hi, the first question I have is what should happen with the current SystemStatus service? Should we just drop it? (Which is an incompatible change, but having two similar services doesn't look appealing either).
More comments inline Bertrand Delacretaz wrote: > Hi, > > Here's a new proposal for SLING-490, for a service that helps find out > when a Sling system is ready to accept requests after startup. > > Last discussion (http://markmail.org/thread/4bwmuwj6qnytmrfw) provided > some good ideas, but I think this is much better, with low coupling > and a possibility for bundles to declare additional required services > before they become active, making it easier to have a well defined > startup behavior. > > The idea is to add an implementation of the ServiceWatchdog interface > shown below, to the sling engine bundle. > See details of the ServiceWatchdog interface below. While the interface might go into the engine bundle I think the implementation should not; like we tried with the SystemStatus service, I think this service should be optional. > The sling engine bundle activator calls > ServiceWatchdog.addRequiredServices based on configuration values read > from BundleContext.getProperty, useful for repository-less setups. This is implementation specific and should go into a separate bundle. > The SlingMainServlet calls ServiceWatchdog.getMissingServices(), and > returns HTTP status 503 if that's not null. That's the only place > where this info is used by Sling itself. > > As soon as the repository becomes available, before making it > available as a SlingRepository service, the AbstractSlingRepository > reads an optional list of additional required services from a > well-known location in the repository, under /system/required-services > for example, I think we shouldn't add this logic to the sling repository (or the bundle where the sling repository implementation is in). This is separate or optional stuff which should go into a separate bundle. Now, the whole watchdog stuff - except the interface - can go in a single bundle; it can act on events like when the sling repository service is registered etc. > * @return null if all required services are present. > * If services are missing, returns a formatted > * string like > * <pre> > * ID:COUNT:CLAZZ:FILTER > * ID:COUNT:CLAZZ:FILTER > * ... > * </pre> > */ > String getMissingServices(); If this method should return a list of status information then we should model it that way and not do clever string concatenation. So something like List<ServiceStatus> getMissingServices(); or Iterator<ServiceStatus> getMissingServices() where ServiceStatus has a getId, getCount etc. As we already tried to solve this problem with the SystemStatus service - which seem to fail, I think we should first do an implementation in the whiteboard and when we're comfortable with it, move this to trunk. Carsten -- Carsten Ziegeler [email protected]
