tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: swallowOutput not working properly?
Date Sat, 15 Aug 2009 04:30:47 GMT
On 08/14/2009 09:57 PM, Eric B. wrote:
> "Mark Thomas"<markt@apache.org>  wrote in message
> news:4A85F872.7040504@apache.org...
>    
>> Eric B. wrote:
>>      
>
>    
>>> Based on that configuration (and swallowOutput documentation) I would
>>> expect
>>> that all logging from my root context would therefor go through
>>> 6root.org.apache.juli.FileHandler 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
> does.
>
> 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
> redirected.
>
> Is this a bug in Tomcat that stdout isn't swallowed before the Listeners are
> instantiated?
>
>
>
>    
>> 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
>    
You got it right. The only time you will get output swallowed is when 
there is an incoming request.
Listeners are in the initialization stage, and will not get swallowed.
> administrators then to configure how and where to log the app's output.
>
>
> Any thoughts or suggestions?
>
> Thanks,
>
> Eric
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message