[
https://issues.apache.org/jira/browse/SLING-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated SLING-3185:
-----------------------------------
Attachment: SLING-3185.patch
The issue occurs because of the way SLF4J performs initialization. When it is
asked for the logger for the very first time it triggers the initialization of
Logging layer and sets its state to {{ONGOING_INITILIZATION}}. Now untill it
gets initialized if any other thread asks for Logger then it returns a logger
obtained from {{SubstituteLoggerFactory}}.
This logger factory gets swapped with actual LoggerFactory when initialization
is complete. See also [1]
So what happens here that by the time Sling LogbackManager tries to obtain the
LoggerFactory the initialization was not complete and it got
{{SubstituteLoggerFactory}} instead of Logback's {{LoggerContext}} resulting in
CCE
As a fix we now make a call to {{StaticLoggerBinder.getSingleton();}} which
ensures that by the time this call returns the Logback based Logger
implementation is binded to SLF4J as it is done in a static initializer
[1] http://bugzilla.slf4j.org/show_bug.cgi?id=106
> ClassCastException in o.a.s.commons.log's LogbackManager at bundle activation
> -----------------------------------------------------------------------------
>
> Key: SLING-3185
> URL: https://issues.apache.org/jira/browse/SLING-3185
> Project: Sling
> Issue Type: Bug
> Components: Commons
> Affects Versions: Commons Log 3.0.0
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-3185.patch
>
>
> with the initial launchpad runmodes patch of SLING-3155, the
> org.apache.sling.commons.log bundle does not start initially, due to a
> ClassCastException in Logback manager.
> Note that there is a circular dependency between this bundle and slf4j.api:
> commons log imports org.slf4j,version=1.6.4 from slf4j.api
> slf4j.api imports org.slf4j.impl,version=1.6.4 from
> org.apache.sling.commons.log
--
This message was sent by Atlassian JIRA
(v6.1#6144)
