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,
>>>
>