Curt Arnold wrote:
On Jun 5, 2008, at 7:19 PM, Jess Holle wrote:
For my own usage I went ahead and completed the a set of changes to
reduce log4j 1.2.x's locking and deadlock potential. The results are
attached and make unabashed use of Java 5 -- as from discussion to
this point it seems clear that there is no interest in making any of
these sorts of changes in log4j 1.2.x yet I felt the need for such
improvements now and only care about Java 5 and later environments.
Thanks for your contribution.
Would you consider signing a Individual Contributor License Agreement
(http://www.apache.org/licenses/#clas)? While the Apache license has
clauses that cover material sent to mailing lists, it is preferred to
have an ICLA on file, particularly for substantial contributions.
I'll have to look into that -- I've contributed code via various Apache
mailing lists and bug reports and have never been asked this.
My take is that the contribution breaks compatibility with JDK 1.3 and 1.4
As a whole, yes, it does. The submission could be made Java 1.3/1.4
compatible if there was interest, but I didn't see interest in changes
of this magnitude in 1.2.x.
and the removal of the synchronization lock on Category could
potentially cause an existing appender to fail that depended on that
lock, though I haven't tried to formulate a failure scenario.
I thought on this and could not find a failure scenario, whereas the
Category method in question shows up as a bottleneck without any changes.
This late in the log4j 1.2.x lifecycle, I'm extremely cautious about
changes that have potential side effects. So I'd -1 applying these to
the trunk at least prior to log4j 1.2.16 and after that only on much
more extensive review that I've been able to give it to this point.
That's fine and good -- which is why I went ahead and used Java 5
features wherever appropriate.
I would not have a problem creating a branch in the sandbox for these
modifications. I don't think it is the path to a log4j 2.0, but could
be convinced otherwise. It is at least some movement which is a good
thing.
I am trying to understand what 2.0 should be and what the path is. The
concurrent sandbox had some good ideas, but I had issues with the
breadth/number of dependencies there.
One question I have not asked in this vein is whether there is any
desire to maintain an "almost certainly 1.2.x compatible" set of base
classes (e.g. perhaps as a separate log4j12-compat.jar module) in 2.0.
That's essentially what my patch is attempting with AppenderSkeleton and
PatternLayout. Most any substantive change can potentially break
compatibility, but I think these should be rather safe.
By the way, I've not had a chance to benchmark my changes yet...
@author tags are pretty common in the log4j code base, however they
are currently discouraged in ASF code as they are seen to contribute
to a territorialism that some code belongs to that particular
individual and no one else should touch it. We haven't gone threw and
removed the existing author tags, but should avoid adding any new ones.
Okay -- my IDE threw those in initially and I didn't know to bother to
remove them.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
