[ http://issues.apache.org/jira/browse/VELOCITY-500?page=comments#action_12451432 ] Nathan Bubna commented on VELOCITY-500: ---------------------------------------
That's a big can of worms. Geir and I debated such things for ages some years ago back when i and others were pushing for adoption of commons-logging. If you'd like, i can dig up some links to those threads. To sum up, I have slowly come over to his perspective and am generally against this approach *when developing component libraries* at this point in my life. In app development, i like the LogFactory approach quite a lot. In application frameworks, i could easily go either way. I see Velocity as a service component, so at this point, i'm basically -1 on this and prefer passing around a logger of some kind. If a section of the component we are developing (Velocity Engine) needs to log debug statements, then it needs a logger. If it needs a logger, then receiving it via ctor or setter is perfectly valid and better for users of the component, even if it is a minor inconvenience to us as developers of the component. > Having to move Log and LogChute objects around pollutes the C'tors > ------------------------------------------------------------------ > > Key: VELOCITY-500 > URL: http://issues.apache.org/jira/browse/VELOCITY-500 > Project: Velocity > Issue Type: Improvement > Components: Engine > Affects Versions: 1.5 beta1, 1.5 beta2 > Reporter: Henning Schmiedehausen > Priority: Minor > > With most logging implementations like log4j or commons-logging, there is a > factory class a method can request a Log object using > Logger log = LogFactory.getLogger("some foo"); > and there is no need to drag a log object through C'tors into internal code > just because one wants to log.debug() from deep inside Velocity. It would be > nice if the LogChute code could also sprout some sort of Log Factory to allow > this. -- 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]
