I think it's been said before that 1.3 may be more of a dead end than anything else. Some interesting things went into it, but the fact that it became so incompatible with Log4j-1.2.xx is a real problem. Is it worth a release or do we just leave it as-is, forever alpha, and move on to 2.0?
From a Chainsaw point of view a lot of work on creating good Appender->Receiver stuff was done, and as I setup a decent environment for our QA and Ops team to use Chainsaw through a firewall (port forwarding) while our app is using log4j 1.2.14, I'm beginning to see a dilemma. serialized LoggingEvents from 1.2 just don't contain lots of info coming out the other end. I then asked myself the question "Should we upgrade our app to use log4j 1.3", and I honestly couldn't say what the quality was, hence the line-in-the- sand email.
>We can then step back and think way beyond 1.3 and come up with a new >vision for what we think is important in enterprise logging. > >Firstly, what do people think of this idea? >As long as we're considering things that have been ignored for a while, what is our official take on Logback? It's basically a realization of what Log4j-1.3 was supposed to be, no? Do we really have plans to best it as Log4j-2.0? I'm not saying we don't. I'm just asking the question. And what are we going to do about SLF4J? It's gained significant acceptance and we've punted on how we are going to approach it; implement it directly, write a wrapper for it (actually, this has already been done by the SLF4J team), or ignore it altogether. So far, we've chosen the latter as the path of least resistance.
My somewhat superficial scan over logback shows a lot of promise from an end user point of view. I would certainly be interested in exploring that as an option. This is where licenses, politics and marketing all come to a head which are never fun.
* Is bringing logback into Apache something the logback community would even remotely consider? Ceki, I know you're watching, do you think that it might obtain wider exposure by coming under the logging.apache.org banner? Is that something that you've ever thought of? I totally respect the community logback has already established.
* Would the Apache dev community even consider looking at that sort of proposal?
Apache log4j has a decent 'brand' behind it, and many people are familiar with it and support it, but we've become stagnant, and perhaps people are moving on. The logback project, if 'absorbed' as a new log4j version could well gain bigger traction quickly purely because of that brand and revitalize logging.apache.org as a broader community (I'm thinking non-java languages here). What we want is a healthy dev community, and right now I'm not sure we(log4j) have one. Curt's been the only one doing anything recently.
I'd be keen to consider starting Chainsaw v3 from scratch along side any post-log4j1.3-type operation and build in exceptional support for enterprise log management, but I'm only one person, and I know many of us are incredibly busy, but we were so active there for a while I think of the potential of what we could achieve! :) From a Java point of view I think many of the Java 1.4+ network library, and java.util.concurrent stuff could be well used in a new logging package.
What you say certainly seems possible. If we're not careful, the log4j project could dwindle into nothing (not that that's a problem, just sad).Do we want to "fully support" 1.3 or just move on? Log4j-1.3 is much larger than 1.2 because of, among other things, Joran. Joran in 1.3 was Ceki's brainchild and continued development of it has long since moved to Logback. I'd be more comfortable letting Logback developers maintain the official version and use it instead of maintaining it ourselves. I can't recall where I read it, but I believe it was stated that Joran could be used in other projects, separate from Logback. Of course, then why not just use Logback? Unless people are truly prepared to put in the time to figure out what the future of Log4j should be (and implement it), I'm afraid that Log4j-1.2.xx is the end of the line, though I'm completely open to being proved wrong.
>Third, who in the dev community (not just committers) is prepared to >provide some effort in this regard. > That's the perennial problem, isn't it?
Indeed. Paul
smime.p7s
Description: S/MIME cryptographic signature
