I would prefer 3 if feasible/doable in a short time frame. The other option I see would be to enhance our launchpad support and allow for different start levels for both, the bootstrap installer and the osgi installer. For now, all bundles in the "boot" level get the same start level. Unfortunately our XML is not that flexible :(
Carsten 2014-01-29 Chetan Mehrotra <[email protected]> > Any comments ... which approach to take? > Chetan Mehrotra > > > On Sat, Jan 25, 2014 at 12:59 PM, Chetan Mehrotra > <[email protected]> wrote: > > Yes such a situation might occur. Some approaches I can think of are > > > > 1. Special case Log bundles when installing bundle in > > BootstrapInstaller. So in the installBundle call [2] we would have to > > add some kind of sorting such that Slf4j related bundles get started > > first *before* any other bundle is started. Currently the order of > > start of bundles at start level 1 is not deterministic. > > > > 2. Similar to above. But instead of special casing using specific file > > name we rely on custom Bundle header. So instead of ordering in > > installBundle we sort the bundle list in startBundle call based on the > > custom header. To support that we add a custom header > > 'x-sling-startup-order' in common log. This would ensure that commons > > log bundle is started first. > > > > 3. This would require change in Slf4j. Currently Slf4j returns a NoOp > > logger [4] in substitution phase. It maintains the list of logger > > names. Instead of that if it returned some kind of substitute logger > > which internally used a delegate (which defaults to NoOp). Later when > > log system is initialized then it can replace the delegate with actual > > logger implementations. > > > > Such a situation was faced in SLING-3189 [3] as well but then we > > worked around it and avoided adding startup order. > > > > Created SLING-3340 [1] for the same. > > > > Chetan Mehrotra > > [1] https://issues.apache.org/jira/browse/SLING-3340 > > [2] > https://github.com/apache/sling/blob/trunk/launchpad/base/src/main/java/org/apache/sling/launchpad/base/impl/BootstrapInstaller.java#L410-L414 > > [3] https://issues.apache.org/jira/browse/SLING-3189 > > [4] > https://github.com/qos-ch/slf4j/blob/master/slf4j-api/src/main/java/org/slf4j/helpers/SubstituteLoggerFactory.java > > > > On Fri, Jan 24, 2014 at 10:39 PM, Justin Edelson > > <[email protected]> wrote: > >> On launchpad startup, I see this warning message: > >> Slf4j is not initialized yet. Delaying Logback support initialization > >> SLF4J: The following loggers will not work because they were created > >> SLF4J: during the default configuration phase of the underlying logging > system. > >> SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger > >> SLF4J: org.apache.sling.commons.logservice > >> SLF4J: org.apache.sling.installer.core > >> SLF4J: org.apache.sling.installer.core.impl.OsgiInstallerImpl > >> SLF4J: org.apache.sling.audit.osgi.installer > >> SLF4J: org.apache.sling.installer.core.impl.PersistentResourceList > >> SLF4J: org.apache.sling.installer.core.impl.EntityResourceList > >> SLF4J: org.apache.sling.installer.core.impl.tasks.BundleTaskCreator > >> SLF4J: org.apache.sling.installer.core.impl.DefaultTransformer > >> SLF4J: org.apache.sling.installer.provider.file > >> SLF4J: org.apache.sling.installer.provider.file.impl.ServicesListener > >> SLF4J: org.apache.sling.installer.provider.file.impl.FileInstaller > >> SLF4J: org.apache.sling.javax.activation > >> SLF4J: org.apache.sling.javax.activation.internal.Activator > >> SLF4J: org.apache.sling.javax.activation.internal.OsgiMailcapCommandMap > >> SLF4J: org.apache.sling.launchpad.installer > >> SLF4J: org.apache.sling.settings > >> SLF4J: org.apache.sling.settings.impl.SlingSettingsServiceImpl > >> SLF4J: > org.apache.sling.launchpad.installer.impl.LaunchpadConfigInstaller > >> SLF4J: > org.apache.sling.installer.core.impl.tasks.RestartActiveBundlesTask > >> > >> Based on http://www.slf4j.org/codes.html#substituteLogger, this seems > >> problematic. I'm especially concerned about the installer loggers > >> being non functional. > >> > >> Is my understanding correct? > >> > >> Thanks, > >> Justin > -- Carsten Ziegeler [email protected]
