[ http://issues.apache.org/jira/browse/VELOCITY-168?page=all ]
Henning Schmiedehausen updated VELOCITY-168: -------------------------------------------- Bugzilla Id: (was: 19140) Component/s: Engine (was: Source) > RFE: switch to commons-logging > ------------------------------ > > Key: VELOCITY-168 > URL: http://issues.apache.org/jira/browse/VELOCITY-168 > Project: Velocity > Issue Type: Improvement > Components: Engine > Affects Versions: 1.4 > Environment: Operating System: All > Platform: All > Reporter: Jens Elkner > Fix For: 2.0 > > > Actually having a quick look at the logging capabilities/usage of velocity, > I feel, that this one makes the package quite unstable and even defeats or > complicates the usage of most wanted features of several logging "system", > no matter whether jdk, log4j or Avalon/logkit (e.g. "source location", since > everything is tunneled through a very limitted LogSystem, logging > stacktraces). > No matter, how one winds the velocity log wrapper, only in some cases, one > gets > the behavior, he expects from "his" logging system. > IMHO, velocity developers should not have to cope with a new LogSystem over > another one, since there is no need to do that and the "new" one is only > a limitted wrapper [for a wrapper for a wrapper ...] for another LogSystem. > As seen (BUGs 19131,19133,19335,19336,19337), this introduces incompleteness, > is cumbersum, halfhearted and another point of unstability/failure/bugs. > So, I suggest to make a transition to one ultra-thin and easy to use wrapper: > the Jakarta Commons Logging package (JCL). > Advantages are clear: Everyone can still plugin the Log system of its choice, > no matter whether jdk1.4, log4j, logkit or any other. Furthermore, > velocity developers can use log.{trace|...|fatal} by just inserting 3 Lines > into their classes and do not need to care about setting up and configuring > the LogSystem, which is actually wrapped. So they can focus on the real > job (velocity) and do not have to take care of the dozen of log systems > flying around. > Also this reduces dependencies and thus point of failures on certain > log sys, since even if the user/developer is not required to configure > anything, since JCL sets up the wrapper in that case: Log4J or JDK1.4 > or as fallback a SimpleLog, which just System.err.print()s all messages. > So there is always one available and no-one should have to use System.err > or system.out to print out stack traces and/or error messages! > So, what do you think? > If you want me to do that, no problem - just drop me a note. > For more information wrt. JCL, see > http://jakarta.apache.org/commons/logging.html . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]