On Wednesday 05 August 2015 15:52:39 Bertrand Delacretaz wrote: > Hi, hi,
> Looking at > https://cwiki.apache.org/confluence/display/SLING/Startup+Handling I'm > wondering if we shouldn't just (or initially) simplify some of the APIs > that currently couple modules to the launchpad in terms of > startup. > > Looking at bundles/extensions/settings for example it seems like it's > only interested in the StartupMode, and I suspect other modules are in > the same case. The dynamics like "is startup finished" don't make > sense anyway with other launchers like Karaf IIUC. > > Currently the only way to get that mode is via > > public interface StartupHandler { > StartupMode getMode(); > boolean isFinished(); > void waitWithStartup(final boolean flag); > } > > which mixes several concerns. How about creating a StartupModeProvider > service API: > > public interface StartupModeProvider { > StartupMode getMode(); > } > > and have StartupHandler inherit from this? > > This would reduce the coupling area between the startup stuff and > client modules, and we can then isolate the StartupModeProvider > implementation in its own bundle which handles just this concern and > is independent of the startup mechanism. > > WDYT? looking closer at StartupMode again it looks like they are only used for sling.run.mode.install.options (which I've never used AFAIR). And they do not seem useful on Karaf with Features either. I wonder if we should break up Sling Settings into API and implementations and provide dedicated Sling Settings services for each launcher/platform. Or make StartupHandler optional. Dedicated services would also allow setting run modes in other ways than by framework property (I'm aware of dangers). Regards, O. > -Bertrand
