<snip>
As for a better commons-logger, I think any bridging API which is *simpler* will result in a net gain. However, my experience also tells me that abstracting independent APIs performing similar tasks is a major undertaking, much more arduous than one would initially suspect.
+1
minimal bridging APIs are difficult. commons-logging is both too large and too unsophisticated. creating minimal but sophisticated code which will work effectively in the many different environments in which java library code is deployed is very non-trivial.
AFAIK none of the people who have worked on commons-logging are satisfied with the current results but IMHO the major mistake we made was to underestimate the complexity of the task. (before people jump to the conclusion that this is just the voice of inexperience, commons-logging did have contributions from some of the most respected coders in jakarta - even ceki added some words of wisdom to the discussions ;)
FWIW the Log interface seems about right. i'd probably now go for a truly minimal API (two public classes) with private classes providing a truly base implementation (log error and fatal to standard error). a single system property or a properties file in the classpath would allow a user to provide an implementation of the actual bridge selection logic. a second jar (containing a properties file specifying the default implementation) would contain all implementations including a bridge selection logic unit that would function correctly in web application environments (by providing isolation per-context-classloader). alternative bridge selection logic units would be provided for other environments.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
