I am new to this
list but have been using log4j for years. I have a possible need to modify the
framework:
I am putting mutable
objects in MDC and this breaks down when using the AsyncAppender (see bug
#5932). As a solution, I would like to do a deeper copy of
MDC.
I have wrapped
calls to Logger via my own Logger, so I can create custom LoggingEvents if need
be that can offer their own getMDCCopy, getMDC and custom serialization (which I am not quite sure is reasonable as I am
not familiar with custom serialization in a subclass),
but I thought another possibility would be to add a pluggable MDC container to
the MDC class so that instead of using the log4j ThreadLocalMap, I could use my
own thread-local map that has a smarter clone
method.
This latter solution
would require a modification to log4j code, which I would like to avoid unless I
can contribute it and get it out of my maintenance loop once the next release
comes out. If this is deemed a legitimate approach, I would think that making
the tlm variable implement a Map (or some subset of Map) would be best. Then the
default ThreadLocalMap could still use a Hashtable (why?) and expose it via the
Map interface. MDC's strategy for creating it's container would be to
instantiate the class configured either via the configurator, system properties
or maybe just MDC.setContainerClass(Class clazz) (I could use some input as to
how best to expose this customization).
Also, LoggingEvent's
getMDCCopy method would need to expect only a Map, not a
Hashtable.
Any ideas or votes
would be helpful as I need a solution to this problem quickly. Also, are CVS
patches required to contribute or can I just send an alternate file (I'll read
the FAQ in case the answer is in there)?
Regards,
Christian
Hall
