Ralph Goers wrote: > > On Apr 21, 2009, at 11:09 AM, Jochen Wiedmann wrote: > >> On Tue, Apr 21, 2009 at 5:01 PM, sebb <seb...@gmail.com> wrote: >> >>> Well, the SLF4J website specifically says it is not necessary to >>> recompile: >>> >>> http://www.slf4j.org/manual.html#swapping >>> >>> i.e. SLF4J chooses the logging implementation based in which logging >>> implementation it finds on the classpath; there must be only one such. >>> >>> I'm not saying SLF4J is better or worse than CL, but they both allow >>> the implementation to be configured without recompilation. >> >> Thanks, that means that I'll drawback from this discussion. I'd only >> like to note that I'd clearly prefer, if we all could stick to a >> single logging system, regardless what. >> > > > Thanks. But I'd really like to get back to what this topic was meant to > be about. > > Commons currently uses Commons Logging. It is a very minimal API (too > minimal if you ask me) and apparently still has some issues with how it > binds to its implementation.
I'm not that experienced in writing portlets or how the portlet container works. Can you please try to explain in more detail what the problem is. Commons Logging works great in a servlet container like Tomcat. Every webapp can have their own version of commons-logging and their own configuration. How does the portlet container use case differ from this? Do you configure Commons Logging explicitly, by using a commons-logging.properties file or are you relying on auto discovery? In my experience you you should *always* configure the logging implementation explicitly if you want deterministic results. > The basic question is, what is next for Commons Logging? Is there any > point in enhancing it to emulate SLF4J? Should it just stay more or less > as it is while it slowly loses its customer base? > > I don't think there is much point in discussing what logging system > Commons projects should use in the future without answering this. > > Ralph > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
