Hello, Eric Crahen wrote: > I've been using the SLF4J API in some of my work and one thing about > it that makes it very awkward, from a dependency mangement standpoint, > is that one of the core APIs - the LoggerFactory - is actually not a > part of the slf4j-api package. Instead, its actually reimplemented in > each of the slf4j implementations. This is awkward for various reasons, > ...... > factory = f; > if(f == null) { > // TODO: Should there be a simple fall back on a System.out logger? > // TODO: Perhaps the simple loggers is included with SLF4J-API and > // TODO: Is selected always, unless another implementation is > provided > }
please do not do that: Put in an RuntimeException with a clear error message what is missing. SLF4J has a very nice concept: api.jar + implementation.jar => working system If someone does not understand that, he is a) ignorant to documentation b) too stupid to understand the documentation (Sorry, I could not resist, I do not want to start a flame war...) In other words: The change of the implementation is done by replacing the implementation jar, do not change this for any case. The next user comes with a proposal: Please put in a property, I want to deliver all implementations just in my war, the customer should use a property when he wants to use my application. Next one: My ugly application server offers "shared" or "common" libraries. I have put this jar in path xy and that jar in the application, it does not work? Could you offer a diagnostic function? Regards Boris _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev