On Jun 27, 2006, at 4:39 PM, Stuart Robertson wrote:
We're considering dipping our toes into log4j 1.3 waters for a not-
far-off production application, and would like to get a read on the
developers' opinion on what areas are stable for production. I
understand there are no guarantees, we won't hold you to it, etc.
etc., but still, you probably know which areas are in flux and
which are already probably how they'll look whenever 1.3 goes live.
We'd actually be using it initially as a backward compatible
replacement for 1.2 in an application where we're experiencing the
dreaded deadlock issues, which it sounds like 1.3 may help resolve.
Anyway, thanks for any input.
Stu
Depends on what issue that you are running into.
If you are running into AsyncAppender related deadlocks, the log4j
1.2 branch should have the recent AsyncAppender rewrite in it. I'm
hesitant to support a log4j 1.2.x release with the new AsyncAppender
since there has been very little feedback on it. The log4j 1.2
AsyncAppender was seriously broken, but had been for a long time and
people either weren't using it, weren't running into the problems or
had worked around them. Though there has been no plans for
additional 1.2.x. releases, there is nothing preventing that decision
being revisited.
If you are talking about deadlocks due the message parameter's
toString() method making log4j calls itself, then I'm not sure that
1.3 buys you anything. I haven't seen a way to solve the problem
that doesn't introduce a potential compatibility problem. Though it
wasn't documented, log4j has never (as far as I know) supported that
scenario and so potentially breaking deployed applications to allow
an improvement for new applications is not something that I could
support in a 1.x release.
My personal feeling is that 1.3 is in a no-win situation. Backwards
compatibility was not rigidly enforced during development. While
there has been some success reworking the code to be compatible with
1.2.x, I do not think that it will ever be close enough to 100%
compatible to be a universally recommended replacement for deployed
applications that are working fine with 1.2.x. However, there are
many issues (primarily involving concurrency) that will require
breaking binary compatibility with 1.2.x to solve, but log4j 1.3.
does not solve them.
I have outline some of my thoughts on log4j 2.0 development in the
past and would love to spend some time brainstorming and getting an
outline and some sample code together. However, I've been resource
constrained due to revenue generating projects. However, I think it
is close to time to opening up a log4j 2.0 branch and getting some
development started.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
