[
http://issues.apache.org/jira/browse/LOGGING-110?page=comments#action_12450996
]
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: 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]
