First let me say that I am in favor of log4j natively supporting the
SLF4J API in 2.0. As I've also stated, I'd have no objection to using
Logback as the foundation for 2.0 if we could. You've made it clear
you are not interested in that. That is disappointing to me but such
is life.
I have no idea what went on before you went off and started logback
and slf4j. I understand that you did a large part of the work, just as
you are in those communities. However, I don't see how the tone of the
message below is going to generate support from Curt and others. While
it might be 100% true, more than likely it will just make them mad.
I've seen the sentiment that log4j must remain 100% backward
compatible. That will continue to be true in 1.2, but I can guarantee
it won't be in 2.0, should it ever see the light of day. It simply
can't in order to really support Java 5 and to fix some of the problems.
As to whether a logging call should take an object or a String. SLF4J
will actually take both. It is "cheating", but since all the
parameters are Objects and they can be passed through the logging
implementation I've used them to pass Objects to my custom appender
without any problem. In Logback they are transient in the logging
event object so they are lost once the event is serialized, but Log4j
doesn't have to do that if they don't want to.
Ralph
On Dec 6, 2008, at 4:02 AM, Ceki Gulcu wrote:
Curt Arnold wrote:
As far as I can tell, there is no significant practical advantage
to our user community to do a direct implementation of SLF4J in
log4j over the facade implementation provided by slf4j.org. I have
never seen a significant performance difference between the two
approaches and a direct implementation has several strong negatives
to the log4j community and users that have been previously discussed.
However, I could see a significant political advantage to SLF4J to
have an implicit endorsement from the ASF and in my mind that is
what this proposal is about. In my mind, java.util.logging has
already won the API standardization war years ago, but it has been
mostly limited the available appenders and configurators. One of
the design goals (https://issues.apache.org/jira/browse/LOG4J2-5)
for log4j 2.0 is to have the back-end classes independent of the
API, so that the bulk of log4j 2 is isolated from the client's API
choice.
I would like to remind you that there would not be a "log4j brand"
without my work. Excluding chainsaw, I wrote 95% of log4j code and
documentation and spent an order of magnitude more time on log4j than
all the other contributors, including yourself, combined. Flaunting
the log4j brand in my face is shameless.
Since you arrived and filibustered the log4j project, it has gone
nowhere. We used make log4j releases regularly. Now we are lucky if
there is one release a year. We used to have a new committer once a
semester. Log4j project was joined only by one new committer in the
last 4 years, namely Ralh. All log4j comitters, excluding Ralph, but
including you, have been nominated by me. Accusing me of wanting to
get political advantage at the expense of Apache and the log4j brand,
is shameless.
If the current majority of log4j committers wish to continue the
status quo, than that's that. However, I propose a path whereby log4j
would converge on SLF4J, an established and popular API. This will
make life easier for thousands of java developers. I wish more of them
could speak up. If you really think that "java.util.logging has
already won the API standardization war years ago" (quoting your own
words) then none of this matters to you. By the way, how can you say
such thing as logging PMC chair, especially since only a small
minority of Java projects use j.u.l.?
We used to have elections for PMC chair every year. There has not been
any since you were elected in 2005. Why is that?
Why hasn't log4j evolved in the last 4 years? Is it because you don't
want it to evolve?
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
