commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Bollinger <>
Subject Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Date Wed, 22 Apr 2009 16:17:52 GMT
Ralph Goers wrote:
> 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 think the most appropriate use case for Commons Logging always has been for small components
intended to be reused in multiple environments, to adapt them to the appropriate logging system
for each environment.  Some larger projects, such as Tomcat, use it for more generalized purposes,
but I think that is a mistake.  Application projects (as opposed to components) should be
encouraged to choose and use a low-level logging framework such as Log4J.  If CL has a way
forward then it is through focusing on its use as an adapter instead of trying to position
it as a general-purpose logging framework.

Furthermore, it seems clear that the class loading issues CL has exhibited, though mitigated
in recent releases, are probably going to continue to present problems for some CL 1.x uses
for the foreseeable future.  (The irony of a convenience feature causing such widespread and
tenacious trouble is not lost on me.)  My solution is to abandon the idea of auto-adaptation,
or to at least discourage its use.  Therefore, I argue that CL should *not* attempt to evolve
toward the SLF4J model, because that's just a different auto-adaptation approach, still likely
to cause trouble.

Instead, CL should focus technology-wise on making it as easy as possible to explicitly configure
logging on both global and per-component bases.  That could mean careful evaluation of defaults,
more or better configuration sources, and / or tools for creating and maintaining logging

Following this strategy will mean that CL's customer base *does* continue to shrink for a
while, because some projects are using it that shouldn't be.  It does not serve anyone well
to try to keep people on CL when it's the wrong tool for the job.  On the other hand, I think
this strategy can ultimately grow the customer base by shedding CL's image problem and providing
a clearer message of when, why, and how to use it.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message