Jess Holle wrote:
o I created an AppenderSkeleton alternative for our own
usage similar to ConcurrentAppender but different in
several respects.
+ ConcurrentAppender relies on all sorts of stuff from
outside the core log4j jar -- I didn't want to.
+ ConcurrentAppender introduces a notion of 'closed'
state and a read-write lock -- I wanted to leave
that to subclasses which need it and not burden
others with this.
+ ConcurrentAppender uses a guard to prevent
re-entrancy. I examined some of my custom appenders
and found this totally unnecessary in some cases --
and thus didn't want this in the base class.
+ Etc...
I also noticed race issues in the concurrent PatternLayout --
specifically between activateOptions()'s handling of patternConverters
and patternFields and format()'s usage thereof.
Such races are real issues for those of us who allow reconfiguration of
layouts, etc, on-the-fly at any time (via JMX in my case -- my own
MBeans as those in log4j had issues).
--
Jess Holle
