i use Axis and log4j 1.2.8 with Debug level and XMLLayout. when log.xml file is open chainsaw complains that log.xml is malformed and log.xml file looks rather strange.
it turned out that format method of XmlLayout is not reenterable and could not be used recursively. however when logging AxisFault format method is used recursively to trace how logging is done. it looks that recursion is only one level deep. quick look at the code of other layouts shows that they could have similar problem.
there are different workarounds. one of them is to use different appender for the offending logger, in my case it will be for org.apache.axis.EXCEPTIONS logger, it works for the current Axis implementation. there are other solutions to use logging recursively without introducing significant overhead:
1. check if the call is recursive, and if recursive do what compilers usually do, push variable on the stack and allocate new instance and pop on exit. recursive logging calls are very rare, so in most cases overhead will be insignificant.
2. extend XMLLayout class with XMLLayoutRecursive class with local variable instead of instance variable, then you can use either of them or both,easy to test difference in performance, just change layout in configuration file. SimpleLayout might be a better candidate for this.
all of the above is for 1.2.8 i have searched archives and wasn't able to find anything, then i checked out cvs and discovered that there is 1.3 version with great changes. among other things there is already a variable guard to check if the call is recursive, and if it is recursive do nothing. when i run Axis with 1.3 the recursive calls were ignored, there were no corrupted messages anymore but some messages were lost.
are there any plans to handle recursive calls in 1.3?
if yes, solutions that i have tried for 1.2.8 could be adapted for 1.3, recursive calls could be checked in AppenderSkeleton where the variable guard now is, but if layout classes are the only ones that are corrupted by recursion than this checks could be moved to Layout class. the second solution, to provide recursive version of layout classes or maybe appender classes in addition to the existing ones, i am not so sure of it any more unless there is a performance issues with the other solution.
if recursive calls are ignored there should be at least a message to inform the user and maybe advise to use different appender for offending logger; or maybe limit the number of recursive calls and notify user. if recursive calls are like in Axis for exception logging then performance is not an issue.
one more question for 1.3: if i understand it correctly, should org.apache.log4j.AppenderSkeleton.doAppend(LoggingEvent) method be final, as it is not supposed to be overridden in derived classes, it is like the Template Method pattern from GoF as it implements the invariant part of the processing, like prevent re-entry, and the javadoc to this method suggests it too.
apologize if this have been discussed before,
oleg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
