Re: [PROPOSAL] Implementing the SLF4J API directly
On 12/6/2008 6:27 AM, Thorbjørn Ravn Andersen wrote: > > I believe that the positive in decoupling the logging implementation > from the application will vastly overshadow any inconvinience in this > regard. Most if not all of the work has been done in the slf4j project. Right. "Most if not all the work has been done". What is left? SLF4J has succeeded in its aim. Congratulations! And I'm not being facetious here. So, what exactly is the impetus to to modify Log4j 1.2 when existing SLF4J binders work well with it? Also, it seems to me that there is a clear advantage to the SLF4J project in maintaining control of its own development. If there's some fundamental fix that needs to be done to all binders it can be done and released quickly; entirely under the control of one project. Why move part of this control out to external projects? What is the advantage of it? Wouldn't that necessitate Log4j to coordinate its release cycles with SLF4J to a certain extent? Such a burden seems totally unnecessary as they can and have lived happily apart up to now. > >> 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 find your statement quite interesting. > > If j.u.l won the standardization war, then how come that there has been > no adapter from log4j to j.u.l from this project? That would be the > perfect way to migrate to a standards based logging solution. > I'm not sure about this whole "JUL has won the API war" thing? I guess I'd have to hear more from Curt about why he believes this? I've never even considered using JUL, but maybe that's just me? However, the question of why Log4j has not provided adapters for JUL in the 1.2.xx codebase is probably because it's somewhat of a dead end, development-wise. It is in maintenance mode. It generally works well, but there are fundamental issues (threading) that can't be fixed without breaking compatibility. So, changes are limited to those that preserve compatibility. The upside is that existing users who have written custom extensions can upgrade and pick up fixes without having to worry about breakage. The downside is that the motivation to innovate remains in hibernation until someone gets cracking on Log4j 2.0. I, for one, seem to have less and less time for this as the years go by; sad but true. > Are you *ABSOLUTELY* certain you want to bring in politics in this > technical issue? In my opinion it will only mudden the waters! > I don't necessarily condone it, but I understand where it comes from. And unless you followed Log4j-1.3/nLog4j/UGLI experience a few years back, you probably won't understand. All I can say is that there's a bit of Dejavu going on here. BTW, notice that Curt did not say no. He said he wants to evaluate the proposal. I think that's reasonable and that demanding immediate consensus is not. I'd also like to hear some more convincing arguments from the SLF4J side about how this proposal provides real benefits over what exists today? See my questions above for more on that. Finally, let's not get lost in tangential issues and concentrate our attention on the original proposal... "I propose that log4j implement the SLF4J API directly. This can be done in the next version of log4j, say 1.3 or 2.0." I think consensus may be quite high if we're talking about Log4j 2.0, as it has already been planned that 2.0 will not be compatible with 1.2.xx. Though keep in mind that some have certain [re]designs in mind for 2.0. If Ceki's conception of 2.0 is simply 1.2.xx implementing the SLFJ, I'm not sure he will gain much traction? And, again, a convincing argument must be (and hasn't been) made as to the benefit of direct extension -vs- the existing model. Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
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]
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 04-12-2008 21:33: Curt has plainly expressed his feelings. What do others think? I think that the slf4j approach is the right way to select the logging framework, and it is the only implementation of this approach I am aware of. My personal "Best Practice" list has "use slf4j" high on the list. As slf4j is an open source project it is not a problem for users to use it and choose the backend they like, but an issue in whether log4j should acknowledge slf4j at all allowing users to avoid reinventing the wheel over and over again, when they find that they need to combine libraries which use java.util.logging and log4j with their own source. I strongly believe that either should the log4j project endorse the practice of using slf4j or provide its own implementation of "java.util.logging-over-log4j" bridging to give the users the best headstart in the world of large applications with lots of independent libraries. If this proprosal is rejected for any reason, the rejecters should at least initiate an alternative and reasonable solution to the problem of multiple logging frameworks in the same application, as this is a real issue encountered by real programmers. Personally I think that the least complex solution would be either to accept a donation of the log4j->slf4j bridge in the standard log4j distribution or go the whole way with Cekis suggestion. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Curt Arnold skrev den 04-12-2008 20:34: 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. Simply the fact that it is impossible for programs using log4j or java util logging to switch between java.util.logging (the Sun standard) and log4j (the de-facto standard) should be enough to say that a solution must be found.The Commons logging project did not work well, and a revised version which do has not shown up. I believe that the positive in decoupling the logging implementation from the application will vastly overshadow any inconvinience in this regard. Most if not all of the work has been done in the slf4j project. 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 find your statement quite interesting. If j.u.l won the standardization war, then how come that there has been no adapter from log4j to j.u.l from this project? That would be the perfect way to migrate to a standards based logging solution. Are you *ABSOLUTELY* certain you want to bring in politics in this technical issue? In my opinion it will only mudden the waters! -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
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]
