commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebastiaan van Erk (JIRA)" <>
Subject [jira] Commented: (LOGGING-110) Implement a Level class and a generic log method in Log
Date Sat, 18 Nov 2006 09:35:38 GMT
    [ ] 
Sebastiaan van Erk commented on LOGGING-110:

I don't understand how this is something that cannot be implemented for certain libraries
(such as Avalon), since the API would require no more information than it needs now.

For example, one could easily implement the log and isEnable methods in the spirit of your
LogUtils methods by using ONLY the commons logging API (and no extra information):

public boolean isEnabled(Priority p) {
  switch (p) {
    case Priority.WARN: return isWarnEnabled();

Note that if you make it possible to use a switch on the priority (in Java 1.5 this could
be done with enums, but in 1.4 and less one could use a byte repesentation of the priority)
I don't think the performance would take a big hit (I don't know how good the JIT optimizer
is, but a switch can be implemented with a jump table; however even without a jump table it
hardly compares to the CPU cycles required to do the actual logging).

Thus one can implement the extra methods in the interface using only the logging API itself.

About the backwards compatibilty, I really meant application code and library code that is
currently using commons logging. I did not mean Log implementations. I guess it would be possible
to put it in a next "big" release (i.e. 1.2) if it is really a big deal. However, the API
is so tiny I think it would be really easy for developers to upgrade their Log implementations
to be usable with the new release.

Finally, about the jdk14 logging API in java 1.4 code: I'm developing library code for java
1.5. But I like the API of commons logging; the log levels are much cleaner (no such things
as FINE, FINER, and FINEST), and the application code looks really clean. Also I like giving
the option of people using my code to choose their logging implementation of their choice.
Even for application code that runs in a servlet container it is nice to give the user the
choice of which logging library to user. So I still see a use for commons logging even though
java 1.4 has its own logging API.

To summarize: I think for a "bigger" release (version jump) it's ok to break the backwards
compatibility with the Log implementations. All application and library will still work fine
without any changes, and nobody is required to upgrade. I think the extension is useful even
for modern java versions (I can't imagine commons logging being obsolete for JDK1.4 and higher).
And I don't think the change will impact people using JDK 1.3 or lower because I seriously
doubt they will even upgrade their commons logging by more than a minor version for bugfixes.

> Implement a Level class and a generic log method in Log
> -------------------------------------------------------
>                 Key: LOGGING-110
>                 URL:
>             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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message