tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric B." <>
Subject Re: swallowOutput not working properly?
Date Sat, 15 Aug 2009 03:57:37 GMT
"Mark Thomas" <> wrote in message
> Eric B. wrote:

>> Based on that configuration (and swallowOutput documentation) I would 
>> expect
>> that all logging from my root context would therefor go through
>> log file.  However, I seem to only be
>> getting some logging captured in the root.log logfile.
>> Is my configuration wrong?
> Yes, no, sort of... You need to keep in mind the way swallowOutput and
> log4j are intended to work.
> swallowOutput is intended to capture direct usage of stdout and stderr
> by a web application. When Tomcat starts, it replaces System.out and
> System.err with custom PrintStreams. These custom PrintStreams use
> ThreadLocals (set when request processing starts, and cleared when
> request processing ends) to capture anything the thread writes to stdout
> or stderr. The captured output is then directed to the appropriate
> logger. If no thread local is set the data is passed through to
> stdout/stderr as appropriate.
> swallowOutput is not intended to capture the output of a logging 
> framework.

I think I understand what you are saying.  And it seems to correlate a 
little with what I have noticed, however, not entirely.  If I understand 
your above comment, the redirection is set on a per-thread basis, meaning 
that everytime Tomcat receives a new request, it sets up the redirections, 
and everytime the request finishes and the thread disappears, the 
redirections are cleared.  Please correct me if my understanding is wrong.

I ran some additional tests this afternoon to try to discover some pattern, 
and noticed the following.  Using a very basic app, I noticed that upon 
startup, a listener does not have its output swallowed, whether through 
log4j or a direct System.out.println.  However, both a filter and a servlet 

This doesn't seem to correlate entirely with your statement above, 
especially given that no request threads are even started yet.

Given that I am using spring which initializes any singleton beans through 
its context listener, I'm wondering if some of the logging issues that I 
have found relate to the fact that the listener's stdout doesn't seem 

Is this a bug in Tomcat that stdout isn't swallowed before the Listeners are 

> When a log message is written to JULI, log4j or just about any logging
> framework there is usually an element of buffering. Typically there is a
> single console appender (names vary between frameworks) that all log
> messages are passed to which are then written out as the buffer fills.
> The thread that does the actual write is probably not the thread the
> generated most of the output. It is quite likely that this write will
> happen outside of the request processing chain and hence won't be caught
> by the swallowOutput code.

> swallowOutput was never intended to support what you are trying to
> achieve. Depending on how data is buffered you may get the results you
> want, apparently mixed up log messages or no log messages at all.

Any reason why swallowOutput wasn't designed so that ALL threads created by 
the context have their StdOut & StdErr redirected instead of just request 
threads?  I would find it more intuitive to find that all output (no matter 
from which thread) created by the context would be captured.

> I think you are trying to combine Tomcat's logging and your
> application's logging in a single file for each web application. That
> should be possible without using swallowOutput providing the app and
> Tomcat use the same logging framework. In this case you shoudl be able
> to configure things such that everythign for an app gets written to a
> single file. Further, if your app does write to stdout then
> swallowOutput can be used to redirect it to a logger.

The way I see it / figure it, the Tomcat administrator should be able to 
configure the logging of the application independent of how the webapp is 
designed.  To require the webapp designer to use the same logging framework 
as Tomcat would not allow for that.  Furthermore, the webapp developers 
shouldn't necessarily need to worry about how or where the logging happens. 
If the webapp simply logs to StdOut, it would allow the Tomcat 
administrators then to configure how and where to log the app's output.

Any thoughts or suggestions?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message