In http://marc.info/?l=log4j-user&m=120898200413495&w=2, Robert Pepersack essentially asks for a method of overriding the use of Exception.printStackTrace() to capture the stack trace of the associated exception. This can partially be done in log4j 1.x by providing a custom layout that returns false for ignoresThrowable and then performs the rendering of the exception as part of the layout. However, it would not affect LoggingEvents that were deserialized. Also, if an AsyncAppender is used, the layout would be rendering an exception after it may have been modified.
The log4j 2 pipeline should not have this issue as the extraction phase done by the layout should pull any info needed from the exception and the responsibility would not be split among WriterAppender, ThrowableInformation and the layout. So likely there is no additional design criteria involved here, just the final design should be checked that it satisfies this use case.
|Status||Resolved [ 5 ]||Closed [ 6 ]|
|Field||Original Value||New Value|
|Comment||[ 这个是log4j的2版本么？为啥没有下载链接啊？？？ ]|