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 <[email protected]>
> 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]
>
--
Carsten Ziegeler
[email protected]
