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)" <ji...@apache.org> on 2005/09/19 07:05:54 UTC
[jira] Updated: (VELOCITY-168) RFE: switch to commons-logging
[ http://issues.apache.org/jira/browse/VELOCITY-168?page=all ]
Will Glass-Husain updated VELOCITY-168:
---------------------------------------
Bugzilla Id: (was: 19140)
Fix Version: 2.0
(was: 1.5)
Description:
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 .
was:
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 .
Environment:
Operating System: All
Platform: All
was:
Operating System: All
Platform: All
Assign To: (was: Velocity-Dev List)
Priority: Major (was: Minor)
I'm moving this to a release 2.0 due to lack of consensus and potential lack of backwards compatibility. Personally, I think we should move towards this. (But I'm not ready to enter a debate at this time).
> 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: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org