Hi, On Tue, Feb 16, 2010 at 9:27 AM, Felix Meschberger <[email protected]> wrote: > ...I have some concerns about the proposed implementation: > > * Returning a formatted string sounds wrong > * We have to define public API, which is not used all > outside of Engine, except for registering something > * We have an issue of where to implement this thing....
Ok, agree with those. > > I am considering the following issues: > > ...* The decision of whether a system is to be considered > ready or not is mainly an administrative task > (rather than a development time decision), we should place > the administrator into a position to be able to configure > this thing.... Ok, but there's one use case where administration cannot happen, it's the first Sling startup, from scratch: 1. OSGi state folder is created, launchpad bundles installed and started 2. JCR repository is created by bundle that provides it, optionally populated by initial content in bundles 3. jcrinstall, if used, installs and starts a number of bundles asynchronously 4. Various services start 5. System is considered ready once all required services are present I'd like this case to be clean from the http point of view, that is Sling should return a 503 for *all* http requests (or a holding page, would be nice) until 5. That's "only" useful in demo/first startup scenarios, but you don't get a second chance to make a first impression... Various schemes involving OSGi configurations might leave room for "uncertainty windows" where the SlingMainServlet might consider the system ready because it hasn't received all the configurations yet. My proposal in the original post prevents this (I think) by having the JCR repository bundle augment the "system ready" configuration *synchronously* in the bundle activator. The SlingMainServlet requires a repository to work, so if the readyness config is modified synchronously in the repository bundle activator, we should get a consistent 503 until step 5. Let's see if that works with your proposal. > * The SlingMainServlet is -- inside of Sling -- the only > party really intereted in some state. Thus introduction of > an externally visible API should probably be prevented > ... * The configuration is provided by the Configuration Admin > service as a factory configuration with the following > properties: > > bundle.symbolic.name > bundle.version (optional, defaults to any version) > count (optional, defaults to 1) > clazz (required) > filter (optional, defaults to "no filter") > > * The SlingMainServlet registers a ManagedServiceFactory > listening for these configurations and maintains an > internal "state machine". This registration can be done > in the SlingMainServlet.activate method (and deregistration > in the SlingMainServlet.deactivate method).... Would that allow for the bundle that provides the repository to augment that config synchronously? i.e. SlingMainServlet receives the configs before the repository bundle's activate() method returns, so that SlingMainServlet considers system not ready immediately. Scenario, to clarify: 1. SlingMainServlet not ready, repository missing 2. bundle that provides SlingRepository starts 3. bundle activator adds a number of configs as you describe 4. Later, SlingRepository service becomes available, SlingMainServlet must already have the list of additional configs, or it might return ready until it receives those I'm not sure how much the ConfigurationAdmin async stuff influences this, if we can guarantee 4. I'm fine with what you suggest. > > * The implementation is part of the Sling Engine bundle > and is private to the Engine bundle. ok > > * The SlingMainServlet uses a simple method: > boolean isSystemReady() > conveying the state. The method should a non-readyness > reason. The SlingMainServlet will just send back 503 > (or 404 ?) if not ready. ok > > * The internal implementation may be registered as a > Web Console plugin (or Configuration Printer) to provide > administrators with: > > * details about the system status > * configuration form to easily manage the > configuration (maybe leveraging the Configuration > Admin support of the Web Console similar to how > the Commons Log bundle does it on the "Sling Log > Support" page. > ok > * Using JCR Install, FileInstall, the Web Console, or other > means of providing configuraiton, administrators may "fill" > the requirements list ok > > Finally the SystemStatus interface is deprecated and the systemstatus > bundle is removed (or moved to some attic location). ok, we can probably remove it, after a vote to make sure no one requires it. Thanks, -Bertrand
