Are you planning on the "binding" still occurring in StaticLogBinder?
If so, in which jar would this class be?
I'll assume "the logging-specific JAR", and ask the next question, which
is, Is it a good idea for the API jar to refer to a class that is not in
the API?
Is the separation really cleaner if the API jar requires classes that
aren't contained in itself?
Some things to think about there.
Come back at me if what I've said doesn't make sense.
Graham.
Ceki Gülcü wrote:
Hello all,
It has been observes that while SLF4J offers abstraction of for
various logging systems through compile-time bindings, it bundles the
SLF4J API and a particular binding in a single jar file. Thus, we
currently have
slf4j-nop.jar
slf4j-simple.jar
slf4j-jdk14.jar
slf4j-jul.jar
each of which contains a copy of SLF4J API and a corresponding binding.
I think it would be somewhat cleaner to separate the API in its own
jar file. Thus, we would have
slf4j-api.jar (just the API with no particular binding)
slf4j-nop.jar (only the nop binding, no API)
slf4j-simple.jar (only the simple binding, no API)
slf4j-jdk14.jar (only the jdk14 binding, no API)
slf4j-jul.jar (only the jul binding, no API)
The only down side to this approach is that the user would need to
deploy two jar files instead of one. The upside is a clearer
separation between API and implementation.
Is there any opposition to this approach?
Your comments are most welcome.
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
