Hello Scott,
Logging in Java needs consolidation. See [1] for an illustration of the current
mess.
As I suggested earlier [2], log4j would help this consolidation by adopting the
SLF4J API natively. Moreover, there *is* a backward compatible migration path.
1) Create a new Logger class in the org.apache.log4j.impl package where most if
not all of the Logger functionality resides.
package org.apache.log4j.impl;
class Logger implements org.slg4j.Logger {
...
}
Users would be encouraged to use the SLF4J API instead of
org.apache.log4j.Logger.
2) Let org.apache.Logger be a wrapper around org.apache.log4j.impl.Logger. All
calls to org.apache.Logger would be delegated to their
org.apache.log4j.impl.Logger equivalents.
package org.apache.log4j;
public class Logger {
org.slf4j.Logger delagateLogger;
Logger(org.slf4j.Logger logger) {
this.delegateLogger = logger;
}
public void debug(Object m) {
delegateLogger.debug(m.toString());
}
...
}
Code using using org.apache.log4j.Logger would continue to work as is, ensuring
backward compatibility, at least as far as the log4j signatures are concerned.
Users who rely on the fact that the message argument was an Object instead of
String would need to modify few lines of code. In the worst case, this change
could cause loss of logging information but would NOT cause compile-time
problems or issues related to method signatures.
Such a move could both re-energize the log4j project and help the larger java
community settle on an API, which imho is urgent.
On another register, there have not been any elections for the PMC
chair since Curt was elected in 2004. As such, elections for PMC chair
is long overdue.
[1] https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp
[2] http://www.mail-archive.com/[email protected]/msg10087.html
Scott Deboy wrote:
Although log4j 1.3 was abandoned, it's fair to say log4j 2.0 hasn't
gotten off the ground either, not sure it ever will.
I agree, logmf is not a good option, this feature needs to be in the
core logging framework.
I think that leaves us with the option of adding useful features to the
current 1.2 codebase, even if it affects backward compatibility. Time
for the log4j committers & interested users to voice their opinions on
'the future of log4j'.
Scott
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
