On Tue, Jun 16, 2009 at 4:24 PM, Jukka Zitting<[email protected]> wrote: > Hi, > > On Tue, Jun 16, 2009 at 3:55 PM, Bertrand > Delacretaz<[email protected]> wrote: >> Not really "at the same time", IMHO the sequence is, in a typical >> Sling launchpad setup: >> >> 1. OSGi framework starts >> 2. Sling engine bundle starts (few dependencies, so starts early) - >> HTTP requests are accepted now, or soon >> 3. SlingRepository becomes available (usally later- more dependencies >> and heavier) >> 4. jcrinstall observer requires SlingRepository, so starts even later >> 5. jcrinstall configs might take 1-2 seconds to be activated, due to >> some internal polling cycles >> >> So, if a request comes in afer step 2, and at step 5. some additional >> SystemStatus configs would have come in, we have a problem. > > What prevents us from making the Sling engine bundle depend on the > repository and jcrinstall bundles?
It's certainly good for the engine bundle to have minimal dependencies, to allow for various use cases. Carsten says he's got a no-repository use case for portals, for example. > ....Additionally it could query > jcrinstall for config status before starting to respond to HTTP > requests.... That would create a dependency to jcrinstall, which is definitely an optional module and should remain as such. > ...If it's a dependency problem, we could perhaps split the engine bundle > so that only a small part depends on the availability of the > repository and jcrinstall. In non-JCR environments that part could be > replaced by something that depends on the alternative backend... That would be an option, if we want to go this route. I'm not too keen on expanding the possible options at the moment, considering the length of this thread ;-) >... PS. I've skipped most of the background for this, so I'm probably > missing something essential here... Be gentle. :-)... That was not too bad ;-) -Bertrand
