|Summary:||(PATCH) Console appender doesn't notice changes to System.out/System.err|
|Product:||Log4j - Now in Jira||Reporter:||Erik Wright <erik>|
|Bug Depends on:|
|Attachments:||Patch to ConsoleAppender.java|
Description Erik Wright 2004-09-03 20:05:44 UTC
The ConsoleAppender can be configured to log messages to Standard Out or Standard Error. Both of these streams may be redirected using System.setErr and System.setOut. In the current implementation, a Console appender stores a reference to it's destination stream when it is initially configured and will continue to use that reference unless it is reconfigured. As a result, a ConsoleAppender will continue to log to the old stdout/stderr destination even after the system stream has been redirected. Since log4j may be automatically configured very early in the application lifecycle (in the case of my project, due to a call to Logger.getLogger in a static member initialization), it can be difficult or impossible to be sure that any necessary redirection takes place before log4j initialization. My patch proposes a solution to this problem. The modified ConsoleAppender overrides the AppenderSkeleton.append( LoggingEvent ) method to verify that the system's stream has not changed since it was last configured. If it has changed, the ConsoleAppender updates itself to use the new reference.
Comment 1 Erik Wright 2004-09-03 20:07:14 UTC
Created attachment 12643 [details] Patch to ConsoleAppender.java
Comment 2 Erik Wright 2004-09-03 20:08:25 UTC
The patch was done against the version of ConsoleAppender.java included in the log4j 1.2.8 distribution.
Comment 3 Ray DeCampo 2005-03-28 01:13:16 UTC
This bug causes lost output when log4j, ANT and JUnit are used to run tests. Since the ANT <junit> task captures System.out and System.err in its XML result files, the best way to keep the logging statements and test results together is to configure log4j to use the ConsoleAppender and write to System.out. Unfortunately, if the <junit> task is forked, System.out is reset after log4j is configured and the logging statements are not captured. There appears to have been no activity on this bug sine Erik submitted it over six months ago. If someone could adopt this bug and apply Erik's patch, that would be great. If Erik's patch is in some way deficient, I'll volunteer to fix the issues if I get reasonable assurance that the resulting patch will be applied.
Comment 4 Stephan Zehrer 2005-04-28 10:49:42 UTC
We have the some problem at the moment. A small workaround ist not to fork the junit task but that helps not allways. A better solution is to fix this problem. Please fix it in next version. (I tried with 1.2.9)
Comment 5 Ceki Gulcu 2005-04-29 18:31:49 UTC
Would it be possible to include a unit test with this patch?
Comment 6 Curt Arnold 2005-05-07 18:58:11 UTC
I've committed v 1.24 of ConsoleAppender that addresses the issue by using nested implementations of OutputStream that redirect to the current value of System.out or System.err. May want to back port to 1.2 after review.
Comment 7 Mark Womack 2005-07-01 19:53:09 UTC
1.2.12 candidate Reopened for 1.2.12 consideration.
Comment 8 Curt Arnold 2005-07-01 20:34:31 UTC
I'll accept back-porting to log4j 1.2.x branch.
Comment 9 Curt Arnold 2005-07-14 21:32:41 UTC
Back ported to 1.2 branch.
Comment 10 Mark Womack 2005-10-18 04:42:27 UTC
Can we look at modifying this fix since it appears to cause #37122. Maybe have old behavior the default and the new behavior controlled by a new flag? I think that maintaining functionality with JBoss in 1.2.X is pretty important.
Comment 11 Curt Arnold 2005-10-19 17:52:56 UTC
It should be fairly trivial, but I'm in the process of packing everything up since I have to be moved out on Friday 10/21/2005, but I can crank a quick one out in a few minutes. Do you have a preference of followReassignment/cacheTarget/etc? On a procedural front, I think it is undesirable to have a bug span releases. I would prefer the do the modification as part of bug 37122.
Comment 12 Curt Arnold 2005-10-19 18:45:32 UTC
Fixed in SVN revision 326604 (trunk) and 326599 (v1_2-branch). Added honorReassignment attribute to configuration with default value of false (1.2.12 behavior). Reported as fix to 37122.
Comment 13 Mark Womack 2005-10-19 18:58:38 UTC
Closing in favor of tracking fix in 37122.