At 12:51 PM 4/3/2007, you wrote:
>
>On Apr 2, 2007, at 7:07 PM, Paul Smith wrote:
>
>log4j 1.3 in my opinion is stuck in a hopeless position. It is too
>incompatible with log4j 1.2.x to ever be recommended as a drop-in
>replacement for log4j 1.2 in a production environment. However, if
>you changed log4j 1.3 to be drop-in compatible with log4j 1.2, then
>you would break any apps that had depended on its 1.3-ness.
Well said. Plus, I think supporting stuff like Joran and other new
stuff that was never given full attention, because active development
stopped abruptly, is risky. A release is expected to be
supported. People expect non-alpha/beta code to work properly. I'm
not sure we can promise that it will work properly? If we can't
support it, we can't release it.
>
>>
>> Secondly, what do people think is left to do before preparing for
>> a fully supported 1.3 release ?
>>
>
>There are still API incompatibilities (http://people.apache.org/
>~carnold/compatibility.html), particularly any user extensions of
>DOMConfigurator (bug 39024) would not work with log4j 1.3.
>LoggingEvent is not serialization compatible (bug 35159).
>LoggingEvent.sequenceNumber can't achieve what it thought it could
>achieve and should be removed (bug 36555, maybe others). The Gump
>runs have been failing for over a year on the scheduler code behind
>the reworked configureAndWatch methods. Mark Womack threw a quite a
>bit of time on that and could not get it diagnosed. And if you
>fixed all that, you would still break apps that didn't explicitly
>call activateOptions(), it would not address the fundamental
>concurrency problems and would still target early JDK's.
>
Again, how can we promise it will work when we know of stuff like this?
>
>On Apr 3, 2007, at 12:10 AM, Jacob Kjome wrote:
>>
>> 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?
>
>I think forever alpha and move on to 2.0.
I think this might have to be the way. Those using Log4j-1.3 for its
"1.3ness" can continue to use it, albeit in alpha state, and if
someone from the Log4j team wants to make further alpha releases,
that's just fine. But I think it's probably going to have to be left
at that; forever alpha.
>
>>
>> >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?
>
>I've been hesitant to deeply examine logback as its code is LGPL'd
>and would want to avoid leakage of logback code into log4j.
Good point. I hadn't thought of that.
> We have
>a bit of a marketing disadvantage here as Ceki has been very vocal on
>the mailing lists encouraging people to migrate to logback and saying
>that log4j development is dead (I'd agree that it hasn't been healthy
>recently, but we've never decided that it is dead). I'm also a bit
>of a lightning rod for Ceki and think any evaluation of logback would
>be better coming from someone else.
>
Yes, I've found the "drop log4j for logback" stuff from Ceki a bit
disheartening. Well, actually I found the whole sudden split from
Log4j after a vote that didn't go his way a bit disheartening. I
think the vote went the correct way, but I wish we could have avoided
the fallout.
>> 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.
>
>logback is always going to be a better logback than log4j 2.0 and
>likely a better log4j 1.3 than log4j 2.0. However, I think that the
>design goals and approaches envisioned for log4j 2.0 will result in
>something valuable to the community.
>
Well put.
>> 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.
>>
>
> From a packaging and maintenance perspective, it has always been
>preferable that SLF4J be a wrapper over log4j. There were never any
>benchmarks provided to quantify the supposed performance benefit of a
>direct implementation. If I remember correctly, supporting SLF4J
>directly introduced a breaking API change when code was recompiled.
>I think the current state is the best for the community. log4j 1.2
>users who want to use SLF4J can do so without forcing them to update
>their log4j 1.2 version and log4j does not have a dependency on SLF4J.
>
...And we don't have to maintain the SLF4J stuff. The only problem
is that repository selectors won't work when using SLF4J wrappers,
but will work using a direct implementation, such as Logback. See...
http://marc.info/?l=slf4j-user&m=117433071915577&w=2
>
>> >Secondly, what do people think is left to do before preparing for a
>> >fully supported 1.3 release ?
>> >
>>
>> 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.
>
>Joran is not the only configuration processor in existence, there are
>likely several in ASF alone (http://ws.apache.org/synapse/
>Synapse_Configuration_Language.html for example). I'd see log4j 2.0
>primarily configured by JMX and expose a configuration API that could
>be driven by a log4j 1.2 compatible property and dom configurators
>and something like the strictxml configurator.
>
If 1.3 is to be released, I think it should be without Joran. Either
enhance DOMConfigurator or use an alternative. Maintaining an early
cut of Joran is not a good idea. Of course, no need to bother if 1.3
stays alpha. 2.0 most certainly shouldn't use Joran. Any chosen
configuration mechanism should keep bloat to a minimum and, maybe, be
optional. Log4j.jar is too big as it is.
I'd forgotten about strictxml. A quick Google search brought up...
http://marc.info/?l=apache-logging-general&m=113981617314339&w=2
http://svn.apache.org/repos/asf/logging/sandbox/strictxml
Interesting stuff!
>
>
>On Apr 3, 2007, at 2:09 AM, Paul Smith wrote:
>>>
>>> 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.
>
>I'd love to hear (in a different thread) what would need to be back-
>ported to log4j 1.2.x to move Chainsaw back over it.
>
A good goal indeed.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
