I don't think you can do a default deep copy unless you overload clone yourself.
I agree with the point about performance. I suppose it depends on how much stuff is in MDC. Our use of AsyncAppender here is to push some longer-running stuff out of the primary thread, so unless the deep copy is particularly bad, I think we'll be ahead. I think your solution is simpler, as long as the copy doesn't need to be more sophisticated than looping the hashtable and cloning the contents. What I've done so far is extend LoggingEvent since I'm trying to do something that doesn't mod the log4j source. LoggingEvent isn't really designed for being messed with, though, so my work feels a bit hack-ish. I think having a completely pluggable MDC container would be nice, but maybe not warranted. Out of curiosity, why is the hashtable used instead of hashmap? This looks like JDK compatibility, maybe? A pluggable container would let folks use a faster collection, though if older style collections are used throughout the framework, I'm not sure how valuable this would be. I suppose it would still have to be synchronized which is where much of the speed loss occurs. At this point, I just need a quick path forward. Let me know what I can do. I am currently on 1.2.7 I believe, so I may have to bring my stuff up to date. -C -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 28, 2004 8:04 AM To: Log4J Developers List Subject: Re: MDC copies Christian, We could simply add a deep MDC copy method to LoggingEvent and add an option to AsyncAppender so that deep MDC copy method would be called. The problem with deep copying, or even with the shallow copying we do currently, is the incurred performance hit. The whole point of AsyncAppender was to improve performance. Given that that deep copying is necessary only when using AsyncAppender, using it starts to become counterproductive at some point. Pardon my ignorance but is there a way to tell a java.util.Collection to deep copy? At 04:48 PM 1/27/2004 -0500, [EMAIL PROTECTED] wrote: >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 -- Ceki G�lc� For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
