You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Henning Schmiedehausen (JIRA)" <ji...@apache.org> on 2006/11/20 22:02:02 UTC

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

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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org


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

Posted by "Nathan Bubna (JIRA)" <ji...@apache.org>.
    [ 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org


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

Posted by "Will Glass-Husain (JIRA)" <de...@velocity.apache.org>.
    [ 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


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

Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/VELOCITY-500?page=comments#action_12451417 ] 
            
Henning Schmiedehausen commented on VELOCITY-500:
-------------------------------------------------

Yeah, VELOCITY-500! 

> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org


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

Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
     [ https://issues.apache.org/jira/browse/VELOCITY-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nathan Bubna resolved VELOCITY-500.
-----------------------------------

    Resolution: Won't Fix

Since i would currently veto such a change and no one is trying to change my mind, i may as well resolve this.  Hope you don't mind, Henning.

> 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