my OSGI bundle containing log4j-over-slf4j has a start-level of 2 (default start level 3) this causes the OSGI framework start it before others and also to resolve all dependent bundles and I can see that the logback.xml was detected (I included ...configuration debug="true"..., so I can see it) I know that some other bundles (with default start level) are using log4j - this was the reason I started log4j-over-slf4j first then ... some bundles later ... my own bundle starts up invoking SLF4JBridgeHandler.install(); and this is done before the first bundle starts using jul-to-slf4j sorry - but this is not very helpful for you I think ;-) ekke cowwoc schrieb:
Maybe the problem has to do with when slf4jBridgeHandler gets invoked. When does your osgi application invoke it? Mine only invokes it in a ServletContextListener. Perhaps something is getting logged beforehand?
Gili
ekke wrote:
I'm using
logback-classic logback-core jcl-over-slf4j jul-to-slf4j log4j-over-slf4j slf4j-api
all together with no problems
...also invoking slf4jBridgeHandler
but inside an osgi application, not from servlet
ekke
cowwoc schrieb:
Ceki,
Any idea about this issue? We can discuss this in more detail on IRC if needed.
Gili
cowwoc wrote:
Hi,
If I deploy:
slf4j-api logback-classic logback-core jul-to-slf4j
I get:
Deploying application in domain failed; Logging factory implementation cannot be null. See also http://www.slf4j.org/codes.html#null_LF
but if I remove jul-to-slf4j from the classpath it works just fine (except, obviously, jul-to-slf4j is disabled).
I am invoking SLF4JBridgeHandler.install() from within a ServletContextListener. Perhaps this is too late somehow?
What am I doing wrong?
Thank you, Gili