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 <jus...@justinedelson.com> 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
