On Wed, Jan 29, 2014 at 3:24 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > I would prefer 3 if feasible/doable in a short time frame.
Seeing the slow release cycle of Slf4j API it might take some time to push for such change and get a release done. I would start a discussion on there DL. >For now, all bundles in the "boot" level get the same start level. Ideally yes only the log bundle and framework fragment bundle start at level 1 and rest are moved to 2. However I was not sure about the impact of changing startlevel on upgrade hence suggested #2 So can we go for #2? Chetan Mehrotra Chetan Mehrotra On Wed, Jan 29, 2014 at 3:27 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > So an ugly option would be to have: > <startLevel level="boot"> > log bundles > </startlevel> > <startLevel level="boot:2"> > everything else > </startLevel> > > Carsten > > > 2014-01-29 Carsten Ziegeler <cziege...@apache.org> > >> 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 <chetan.mehro...@gmail.com> >> >> Any comments ... which approach to take? >>> Chetan Mehrotra >>> >>> >>> On Sat, Jan 25, 2014 at 12:59 PM, Chetan Mehrotra >>> <chetan.mehro...@gmail.com> 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 >>> > <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 >>> >> >> >> >> -- >> Carsten Ziegeler >> cziege...@apache.org >> > > > > -- > Carsten Ziegeler > cziege...@apache.org
