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/05 13:33:18 UTC

[jira] Updated: (VELOCITY-168) RFE: switch to commons-logging

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