"Mark Thomas" <ma...@apache.org> wrote in message news:4a85f872.7040...@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 administrators then to configure how and where to log the app's output. Any thoughts or suggestions? Thanks, Eric --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
