You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Will Glass-Husain (JIRA)" <de...@velocity.apache.org> on 2008/08/21 03:24:44 UTC

[jira] Commented: (VELOCITY-500) Having to move Log and LogChute objects around pollutes the C'tors

    [ https://issues.apache.org/jira/browse/VELOCITY-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624218#action_12624218 ] 

Will Glass-Husain commented on VELOCITY-500:
--------------------------------------------

Makes a lot of sense to me.   And since we had those debates, the industry has moved even more to an Inversion of Control philosophy that the logger approach follows.

> Having to move Log and LogChute objects around pollutes the C'tors
> ------------------------------------------------------------------
>
>                 Key: VELOCITY-500
>                 URL: https://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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org