[ http://issues.apache.org/jira/browse/VELOCITY-168?page=comments#action_12412754 ]
Michal Maczka commented on VELOCITY-168: ---------------------------------------- Please - don't do this! :) Why would anybody be forced to included yet another dependency to use velocity even if his/hers application which uses velocity is not using any logging? The best solution which I am aware for such situation is to use so called Monitors. It means: use events to inform "subscribed" events listeners about something "interesting" which occurs inside velocity engine - e.g "template loaded", "parsing error" etc. Then if somebody is willing to log those events to log file - he can very easily create event listener(s) (probably just one class!!) which will log incoming events using what ever logging API he/she wishes. > RFE: switch to commons-logging > ------------------------------ > > Key: VELOCITY-168 > URL: http://issues.apache.org/jira/browse/VELOCITY-168 > Project: Velocity > Type: Improvement > Components: Source > 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]
