logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy" <sde...@comotivsystems.com>
Subject RE: Remove TRACE? Was: [VOTE] Modified Release Proposal
Date Wed, 25 May 2005 23:57:22 GMT
I think we're both right.

Some users just want one more level of verbosity and they'd probably like logger helper methods.
 Fine.  Some users would like more granularity than trace without having to write their own
custom level class.  Fine.

There is an easy way to provide both at the same time.

Scott

-----Original Message-----
From:	Mark Womack [mailto:womack@adobe.com]
Sent:	Wed 5/25/2005 4:01 PM
To:	'Log4J Developers List'
Cc:	
Subject:	RE: Remove TRACE?  Was: [VOTE] Modified Release Proposal
- What happens in a tool like chainsaw that is receiving logging events from
several sources, each of which could have their own custom Levels defined?
I imagine this happens today when a developer extends log4j to support their
levels?

- What will happen if a library developer defines a set of custom levels
they use in their library, and the library user defines their own set of
custom levels, etc.  All those levels are going to be resolved, etc?  What
if they both end up using the same name/key for the level?  There just seems
like there can be room for confusion and frustration here as the various
levels are resolved/reported.

- Are we sure that users want to be able to define ANY set of levels, or do
they just want slightly more flexibility by having one more level like trace
to choose from?  I really think that there is something to be said for
having a predictable set of levels that is known across various
code/libraries.  If it is too flexible, it is going to lead to confusion.  I
think there was a feeling that the jdk logging went overboard with FINE,
FINER, FINEST and maybe just adding TRACE is good enough.  But to allow any
arbitrary set of levels, I'm not so sure.

- Curt makes a good point about how to handle this in configuration files,
but I'm sure it can be worked out.  One should be able to define levels from
within the config file.  <level key="TRACE" value="3000"/>

-Mark

> -----Original Message-----
> From: Scott Deboy [mailto:sdeboy@comotivsystems.com]
> Sent: Wednesday, May 25, 2005 3:00 PM
> To: Log4J Developers List
> Subject: RE: Remove TRACE? Was: [VOTE] Modified Release Proposal
> 
> This shouldn't be a factory.  I don't want to have to manage the instance,
> but I do want to reference the instance from anywhere (this is assuming
> support for levels outside of TRACE, regardless of if we still support the
> trace helper methods in loger).
> 
> CustomLevelRegistry may make more sense, with statics for accessing and
> registering levels (requiring syslog level support seems like a pain -
> maybe we can have two 'register' methods, one that supports syslog levels,
> one that doesn't but sets all custom levels to the same syslog level.
> 
> CustomLevelRegistry.register(3000, "TRACE");
> 
> logger.log(CustomLevelRegistry.getLevel("TRACE"), "my message");
> 
> No need to have CustomLevelRegistry extend Level - it can live in
> org.apache.log4j along with Level.
> 
> If we still feel like supporting trace helpers in logger, fine.  We do
> need to look at Level's toLevel method because it defaults to DEBUG if it
> doesn't recognmize the level (this will need to change).
> 
> 
> Scott
> 
> -----Original Message-----
> From:	Curt Arnold [mailto:carnold@apache.org]
> Sent:	Wed 5/25/2005 2:06 PM
> To:	Log4J Developers List
> Cc:
> Subject:	Re: Remove TRACE?  Was: [VOTE] Modified Release Proposal
> 
> I was surprised that it was hard to find a lot of previous discussion
> or previous bugs on the issue.  If anybody else has links to relevant
> discussions, please add them.  Here are some that I found:
> 
> 
> Recent log4j-user discussion (assume existence of problem): http://
> marc.theaimsgroup.com/?l=log4j-user&m=111253143214177&w=2
> Commons-dev patch submission to http://marc.theaimsgroup.com/?
> l=jakarta-commons-dev&m=107472058005673&w=2
> Commons-dev thread (followups appear as distinct topics) http://
> marc.theaimsgroup.com/?l=jakarta-commons-dev&m=106865687610260&w=2
> 
> As far as I can reconstruct, Apache Geronimo wanted a distinct level
> lower than debug and had trace() added to Jakarta Commons Logging.
> Without that change, I believe that most code that used JCL could be
> converted to use log4j simply by changing the package names and
> switching Log and Logger.  The JCL bridge to log4j just treated trace
> as a synonym for debug where the JDK 1.4 logging maps debug() to
> Level.FINER and trace to Level.FINEST.
> 
> So trace is a special case due to its "endorsement" by JCL.  There
> are a couple of distinct issues:
> 
> JCL/log4j client code compatibility:
> Switching JCL code that uses org.apache.commons.logging.Log.trace()
> to log4j would require adding an explicit org.apache.log4j.Logger.
> 
> JCL mapping of trace calls to level lower than Level.DEBUG
> The major roadblock is the lack of a public constructor for
> o.a.l.Level.  I think the approach used in tests/java/org/apache/
> log4j/xml/XLevel.java is problematic  since adding a custom
> implementation class would cause problems for SocketAppender et al to
> fail if the class is not available.  A derived class definition could
> be used to bypass the access control on the constructor and would
> might be an appropriate way to address the issue:
> 
> class final CustomLevelFactory extends org.apache.log4j.Level {
> 
>     /**
>      *   Private, non-functional constructor.
>      */
>      private CustomLevelFactory() {
>          super(-1, "", -1);
>          throw new NotImplementedException();
>     }
> 
>     //
>     //   since we are in extension of Level we can access the
> protected constructor
>     public static final org.apache.log4j.Level createLevel(
>          final int severity,
>          final String name,
>          final int syslogLevel) {
>              return new Level(severity, name, syslogLevel);
>      }
> }
> 
> class Log4JLogger {
>      private static final Level TRACE = CustomLevelFactory.createLevel
> (5000, "TRACE", 7);
>      public void trace(Object message) {
>            getLogger().log(FQCN, TRACE, message, null );
>      }
> 
> }
> 
> In a perfect world (aka 2.0), Category would disappear and Level
> would be final with a public constructor.  That would make life
> easier in general but CustomLevelFactory would need to be changed to
> not extend Level and call the public constructor.
> 
> The final area would be in parsing configuration files that contain
> "TRACE" (or any other place were you need to convert a Level name
> back to an object), but the only place that I can think of right now
> are in the configuration parsers.  The code might be made more
> general so that if it encounters a name like "5000" it will parse it
> as an integer and fabricate a level with that value which would be
> sufficient for configuration purposes.
> 
> To recap my non-exhaustive analysis:
> 
> trace() is special since it is in JCL.
> 
> JCL should be able to map trace() to a distinct level than debug() by
> using hacky CustomLevelFactory to create an instance of Level with a
> custom name and value.
> 
> Other custom levels should be available using the CustomLevelFactory
> approach without any code changes (excluding configuration).
> 
> Setting a threshold to a custom level would require modifying the
> configuration code or Level.toLevel to fabricate a new level if the
> argument is a string representation of an integer which would allow
> stuff like:
> 
> <root>
>      <level value="5000"/>
> </root>
> 
> Or providing a mechanism to inform the configurators of new levels to
> recognize:
> 
> JoranConfigurator config = new JoranConfigurator();
> const.addLevel(MyCustomLevels.TRACE);
> config.configure(...);
> 
> 
> which would allow you to do:
> 
> <root>
>      <level value="TRACE"/>
> </root>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 



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





Mime
View raw message