Hi, On Tue, Feb 16, 2010 at 9:27 AM, Felix Meschberger <[email protected]> wrote: > ...So, here is my proposal: > > * 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)....
I don't think this allows for my "synchronous configuration" scenario without special precautions. Taking the SlingRepository service as an example, the scenario is: 0. SlingMainServlet started, SlingRepository service not present -> system not ready, servlet returns 503. 1. SlingRepository service starting, activate() called 2. SlingRepository provides additional readyness configurations C, using Configuration.update(...) in its activate() method. 3. SlingRepository.activate() is done, SlingMainServlet sees SlingRepository service, declares system ready. 4. SlingMainServlet is notified of configurations C, might happen later than 3. as Configuration.update() is processed asynchronously by ConfigurationAdmin. So between 3. and 4. we have an unwanted switch to system ready and back, which I want to avoid. One possible workaround is to register the SlingMainServlet as a ConfigurationPlugin, so that it is informed of Configuration.update() calls synchronously. Feels a bit hacky? Or we go back to my ServiceWatchdog interface. I agree that that introduces more coupling than what you suggest, but it's simple and guaranteed to work synchronously. Thoughts? Other suggestions? -Bertrand
