Hi,

Replying to this message, but my response applies to the complete thread.

Let's step back a second and look at what we really need to know to be
able to decide the system is ready or not. And who is responsible to
provide this knowledge.


(1) The most basic criterion for the system to be ready is the available
of certain services.


(2) There must be away to specify which services are required.


Now, this is very simple and easy: As Alex Klimetschek proposes we are
using ConfigurationAdmin for this. Each service can be described by a
few properties:

   (a) Service Name
   (b) Service Filter
   (c) Number of services

The configuration of required services is a multivalued string property
of the format

    [ number ] ( serviceName | serviceFilter )

where

    number        is an optional positive number of required services
    serviceName   is the name of a service interface
    serviceFilter is a service filter according to 3.2.6, Filter Syntax

The system status service itself :

   * requires the ConfigAdmin service to be present
   * registers as a ManagedService to receive the configuration

Thats basically all. Very simple, very lean.


Regards
Felix

Bertrand Delacretaz schrieb:
> Hi,
> 
> Felix and Carsten made some comments in SLING-490 that are probably
> worth discussing here.
> 
> Here's how I view this service, comments are welcome.
> 
> 1. The goal is to return a 503 status until the system is ready to
> process requests.
> 
> 2. Defining readyness is hard due to the dynamic nature of OSGi and
> especially Declarative Services. My idea is to use scripts found under
> /system/sling/status in the JCR repository to let programmers define
> what they require for their system to be ready.
> 
> 3. If it finds an *.foo script there, the default SystemStatus service
> will complain if no script engine is found to execute *.foo scripts.
> This avoids problems with requests coming in while the required script
> engines are not started yet.
> 
> 4. Currently, a SystemStatus service is required for the
> SlingMainServlet to operate. I'm not sure how to avoid this coupling -
> if the SystemStatus service is made optional and a request comes in
> before it is started, the SlingMainServlet might erroneously think the
> system is ready.
> 
> 5. As the default SystemStatus implementation uses scripts, it is not
> practical to make it a part of the engine bundle, which has no
> dependency to script engines at the moment. Hence the separate bundle.
> 
> I'm happy to rediscuss this if needed, but I think giving a
> customizable server-side way for people to "compute" the readyness of
> their Sling system is a must.
> 
> -Bertrand
> 

Reply via email to