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]
