The "discovery" is in the binding artifact. If you place
slf4j-jdk14.jar on the class path, this means that SLF4J will delegate
to j.u.l. If slf4j-log4j12.jar is on the class path, SLF4J will
delegate to log4j, and so on. "Discovery", if you can call it that, is
done by the JVM's most basic class loading mechanism (the one you
learn about on your first day of Java). If that is still unclear, then
I suggest you look at LoggerFactory [1] and the StaticLoggerBinder
class found in any of the bindings, for example [2] for the
j.u.l. binding and [3] for the log4j binding. SLF4J's discovery is
really as dumb as it gets. I don't think you could make it any dumber
which incidentally is the purpose of the exercise (dumb in this case
implies robustness).
As for the second part of your question, the instant the LoggerFactory
class binds to a logger framework, it is bound until the LoggerFactory
class is removed from memory. If the LoggerFactory class is shared
between several components, each component will use the same
underlying logging framework. This behavior is radically different
than commons-logging. However, in practice, users will rarely, if
ever, want to have their applications log into different logging
frameworks.
If (and it's an important if) Glassfish exports LoggerFactory to its
hosted applications on account of its loading SLF4J into memory, then
you will have all hosted apps sharing the same LoggerFactory
instances. Jetty, which uses SLF4J internally, solves this issue by
not exporting SLF4J classes to hosted applications. I suggest you go
this route as well, i.e. isolate SLF4J and have users ship their own
slf4j-api.jar and binding artifact within their application. Would
that be possible?
[1]
http://slf4j.org/xref/org/slf4j/LoggerFactory.html
[2]
http://tinyurl.com/jdk14-binding
[3]
http://tinyurl.com/log4j12-binding
Sahoo wrote:
> Thanks for pointing it out. Now I see why it is not appropriate to
> bundle them together. It is still not very clear how the discovery takes
> place. Does it use reflection to find out which binding is available? It
> also does not specify if the binding has to be made visible to api jar?
> Can you clarify? If yes, we have a problem, since we can't share one
> slf4j api jar among multiple isolated apps without forcing each of them
> to use the same binding.
>
> Sahoo
>
> Ceki Gulcu wrote:
>>
>> Have a look at the SLF4J manual at http://slf4j.org/manual.html, in
>> particular the section entitled "Binding with a logging framework at
>> deployment time" which explains how discovery is done.
>>
>>
>>
>> Sahoo wrote:
>>> Does sljf4j not use Service lookup to locate log implementations? Can
>>> you please tell us how it discovers log implementations and why
>>> bundling those two artifacts together affects the discovery process?
>>> Yes, we know slf4j is in central repo, but we have a requirement in
>>> GlassFish project to build external code in our own environment,
>>> hence we are promoting our own binaries.
>>>
>>> Sahoo
>>>
>>> Ceki Gulcu wrote:
>>>> Hello all,
>>>>
>>>>
>>>> Just wanted to observe that combining slf4j-api and slf4j-jdk14 in a
>>>> single module will prevent slf4j from being able to use any logging
>>>> framework other that j.u.l. within Glassfish, which partially defeats
>>>> the purpose of SLF4J as a logging abstraction. Is keeping the slf4j
>>>> artifacts split an option?
>>>>
>>>> btw. 1.5.9.RC1 is already available in the central maven repository.
>>>>
>>>> Cheers,
>>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch