Hi Nils,
Without detailed info it is hard to tell, but as a general rule,
embedded components should not attempt to configure logging. See
[1]. By analogy, they should also not include an slf4j-binding in
their distribution.
As of SLF4J v1.6.0, in the absence of a binding, slf4j will default to
an NOP implementation. This further restricts the number of cases
where a library would need to include a binding in its
distribution. See [2].
Given the above, it looks like both GMaven and Magnolia CMS could be
alerted about the conflict you are experiencing.
[1] http://slf4j.org/faq.html#configure_logging
[2] http://slf4j.org/codes.html#StaticLoggerBinder
On 07.10.2010 18:03, Nils Breunese wrote:
Robert Elliot wrote:
Thanks for the fast response!
Gossip and log4J are both logging systems.
I found that it is a 'plugin for SLF4J', but I didn't know that it was a
logging system in its own right.
The big question is why your modules think they need to specify a logging
system; in the case of gmaven I would guess because you are using it embedded
but it can also run stand-alone.
GMaven is embedded in our build to generate Java stubs in a mixed Java/Groovy
submodule. gmaven-runtime-1.7:1.3 brings in gmaven-runtime-support:1.3, which
brings in gshell-io:2.0, which brings in gossip:1.0.
In the case of the other module I would guess that it's a legacy one, and you
should be using log4j-over-slf4j to redirect log4j to it (unless you actually
want to use log4j).
The other module uses Magnolia CMS, which via a couple of links brings in both
slf4j-log4j12 and jcl-over-slf4j according to mvn dependency:tree.
You could try excluding gossip and log4j explicitly (by giving them "provided"
scope) and choosing your own logging implementation such as logback.
If you do not it will be an arbitrary consequence of classloading order as to
which logging system (gossip of log4j) ends up handling any log calls to SLF4J.
Ok thanks, we'll look into this.
Is there anything which should be reported as a bug to either GMaven or
Magnolia CMS, or is this just our combination of the two?
Nils.
------------------------------------------------------------------------
VPRO
phone: +31(0)356712911
e-mail: [email protected]
web: www.vpro.nl
------------------------------------------------------------------------
_______________________________________________
slf4j-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-user
