Re: [slf4j-dev] Service Provider Interface (using jcl104 -over-slf4j.jar with axis.jar)

[Boris Unckel]

Hello,

> Von: Ceki Gülcü <listid at qos.ch>
> 1) Assuming a child-first class loader setting, each web-application can 
> have its own separate copy of slf4j-xyz.jar.
> 
> 2A) Single copy of slf4j-jar with logging separation performed by the 
> underlying logging system, see for example JNDIContextSelector in log4j.
> 
> 2B) Apply the same techniques used for JNDIContextSelector in SLF4J
> itself.
> 
> >To go further: The static approach chosen in jcl104-over-slf4j is not
> >"Plug'n'Play" with the chance to ignore Classloader issues if one wants
> to
> >have two configurations at the same time in the same virtual machine.
> 
> I fail to understand the above paragraph. Could you perhaps care to 
> rephrase it?
I apologize for my English - for complex things I should read twice to
ensure I am writing what I want to express.
1) Is fine, putting the jars in will allow to use plain commons-logging in
WebApp A and jcl104-over-slf4j in WebApp B.
This does not work if there are shared classes using the commons-logging
API. The use of shared-libs is not good as I learned in the last months but
some libs are recommenend to be in a shared classloader. As result you
cannot ignore this scenario.
At this point configuration comes into the game - as I tried to express with
the words not "Plug'n'Play".

2a) is a misunderstanding because of my bad description. I did not mean the
configuration of the underlying log API, this is not a problem of a wrapper
. I just meant the deterministic way of the wrapper to choose the underlying
API.
2b) SLF4J should configure the underlying logger? Hm, sounds complex.

As long as people want to have different log APIs for different WebApps in
the same server maybe a third one for the server itself, people have to care
for the configuration and for classloading. I think it is not possible to do
that with just JAR replacement.

Regards
Boris