Ceki/Sahoo,
Integrating weld in GlassFish requires the following slf4j and cal10n
artifacts:
http://repo2.maven.org/maven2/org/slf4j/slf4j-api/1.5.9.RC1/
http://repo2.maven.org/maven2/org/slf4j/slf4j-ext/1.5.9.RC1/
http://repo2.maven.org/maven2/org/slf4j/slf4j-jdk14/1.5.9.RC1/
http://repo2.maven.org/maven2/ch/qos/cal10n/cal10n-api/0.7.2/
If we can't combine the artifacts into one, then we'll need repackage
all 4 of them to separate OSGi bundles?
Ceki, your suggestion is to have hosted app bundle it's own
slf4j-api.jar and binding artifacts. Does that mean we can bundle the
other slf4j artifacts and cal10n as one artifact and package them as an
OSGi module.
Please let us know how to proceed so we can integrate weld and slf4j in
GlassFish v3.
Thanks,
Jane
Ceki Gulcu wrote:
>
> 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
>>
>