"Filip Hanik - Dev Lists" <devli...@hanik.com> wrote in message news:4a8639f7.50...@hanik.com...
>> 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. >> >> >> 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. Any particular reason(s) why the design for swallowOutput was only to handle incoming requests and not the context as a whole? Secondly, how does a Filter and Servlet outputs get swallowed properly upon initalization? There is no request at that point either, is there? Thanks, Eric --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
