Bug 31056

Summary:	(PATCH) Console appender doesn't notice changes to System.out/System.err
Product:	Log4j - Now in Jira	Reporter:	Erik Wright <erik>
Component:	Appender	Assignee:	log4j-dev <log4j-dev>
Status:	CLOSED FIXED
Severity:	normal	CC:	log4j-dev, wenjun
Priority:	P3
Version:	1.2
Target Milestone:	---
Hardware:	All
OS:	All
Bug Depends on:
Bug Blocks:	37452
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.

Comment 14 Curt Arnold 2007-08-22 15:44:26 UTC

*** Bug 32906 has been marked as a duplicate of this bug. ***