[ 
http://issues.apache.org/jira/browse/LOGGING-110?page=comments#action_12450911 
] 
            
Simon Kitching commented on LOGGING-110:
----------------------------------------

I agree it would be convenient to have a log level that can be queried and a 
generic log method that takes a level.

However there are logging libraries that don't have this info available; it 
would therefore not be possible for commons-logging to implement this when 
wrapping those libraries. In particular, the Avalon framework's Logger class 
does not suport this. Ok, this particular log lib is now rather obsolete but we 
don't know how many other logging libs out there are like this.

Although you state that this "would not break backwards compatibility", it 
seems to me that it does; remember that users can write their own logging 
adapters.  Compiling an old logging class against the new API would fail. 
Running an old binary logging class with the new API would work until someone 
called one of the new methods at which time a MethodNotFound exception would 
occur.

An alternative might be to write a LogUtils class:
  Log log = LogFactory.getLog("someCategory");
  if (LogUtils.isEnabled(log, Priority.WARN)) {
      LogUtils.log(log, Priority.WARN, "a message")
  }
Where LogUtils has stuff like:
  public boolean isEnabled(Log log, Priority p) {
    if (p == Priority.DEBUG) {
      return log.isDebugEnabled();
    } else ....
  }
This would have a performance impact, however, that would probably not make it 
worthwhile using.

I'm not sure what code would make use of this new functionality anyway. Any 
code that is targetted at java 1.4 or later should probably use the jdk14 
logging API directly (with an alternate underlying implementation plugged in to 
replace the pathetic default implementation). And application code should know 
what logging lib it is distributed with and code to that lib directly. So the 
only user of this stuff would be new framework or library code targetted at 
java 1.3 or earlier; there's not a lot of that around I would expect...

> Implement a Level class and a generic log method in Log
> -------------------------------------------------------
>
>                 Key: LOGGING-110
>                 URL: http://issues.apache.org/jira/browse/LOGGING-110
>             Project: Commons Logging
>          Issue Type: New Feature
>    Affects Versions: 1.0.4
>            Reporter: Sebastiaan van Erk
>
> The Log API does not have a generic log method and there is no generic Level 
> class. Since the levels which commons logging provides are fixed and since it 
> would not break backwards compatibiliy I would like to suggest that these are 
> added. To be more specific, I would like to see the following methods added:
>  void         log(Level level, Object message)
>            Log a message with the specified log level.
>  void         log(Level level, Object message, Throwable t)
>            Log a message and exception with the specified log level.
>  boolean isEnabled(Level level)
>            Is the specified logging level currently enabled?
> As an extra feature of the level class one could have string and integer 
> conversions to and from log levels.
> These features would allow one to use commons logging in more complex 
> situations without have to rely on specific logging implementations.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to