Re: swallowOutput not working properly?
"Filip Hanik - Dev Lists" 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
Re: swallowOutput not working properly?
On 08/14/2009 09:57 PM, Eric B. wrote: "Mark Thomas" 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 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput not working properly?
"Mark Thomas" 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
Re: swallowOutput not working properly?
Eric B. wrote:
> Hi,
>
> I'm trying to get Tomcat to log the output each context individually in its
> own log file.
>
> I tried using the swallowOutput in my object definition, but am
> getting some really weird results from it. My webapp uses log4j to do its
> logging with its own log4j.xml file within the webapp, and all log4j's
> output is
> defined as using the org.apache.log4j.ConsoleAppender.
>
> My context.xml file is:
> conf/Catalina/localhost/ROOT.xml:
> swallowOutput="true">
>
> global="jdbc/eppe"
> type="javax.sql.DataSource" />
>
> global="mail/dame"
>type="javax.mail.Session" />
>
>
>
>
> ${catalina.base}/conf/logging.properties:
> handlers = 1catalina.org.apache.juli.FileHandler,
> 2localhost.org.apache.juli.FileHandler,
> 3manager.org.apache.juli.FileHandler,
> 4admin.org.apach\e.juli.FileHandler,
> 5host-manager.org.apache.juli.FileHandler,
> 6root.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
>
> 6root.org.apache.juli.FileHandler.level = ALL
> 6root.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
> 6root.org.apache.juli.FileHandler.prefix = root.
>
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].level =
> ALL
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].handlers =
> 6root.org.apache.juli.FileHandler
>
>
>
> 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.
>
> It is extremely confusing; there doesn't seem to be any pattern. Some
> webapp logs go to root.log, other still are displayed on stdout, and
> therefore in catalina.out. Like I said, all log msgs in the webapp use the
> same log4j ConsoleAppender.
>
> I'm running Tomcat 6.0.18. I searched through the changelog for 6.0.19 and
> 6.0.20 and don't see anything that relates to this, so I am wondering if
> this is an issue that still exists.
>
> 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.
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. Even if it were captured, the chances are the
data won't be where you want it.
To put this another way, the intended usage of swallowOutput is:
webapp -> stdout -> swallowOutput -> file
You are trying to do
webapp -> logging framework -> stdout -> swallowOutput -> file
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.
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.
I should add I haven't tested this so YMMV.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput not working properly?
"Filip Hanik - Dev Lists" wrote in message news:4a849e55.1030...@hanik.com... > On 08/13/2009 02:09 PM, Eric B. wrote: >> "Filip Hanik - Dev Lists" wrote in message >> news:4a84706e.2040...@hanik.com... >> >>> Tomcat doesn't use log4j in v6 in its standard distribution. You have to >>> build an adapter for that >>> >> >> I don't understand at all. Can you please clarify? All I am trying to >> accomplish is have the stdout from my webapp "swallowed" and redirected >> to >> tomcat's logger. > this works for me, and the output ends up in the localhost_ log file Is your webapp using log4j to do its logging? Thanks, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput not working properly?
On 08/13/2009 02:09 PM, Eric B. wrote: "Filip Hanik - Dev Lists" wrote in message news:4a84706e.2040...@hanik.com... Tomcat doesn't use log4j in v6 in its standard distribution. You have to build an adapter for that I don't understand at all. Can you please clarify? All I am trying to accomplish is have the stdout from my webapp "swallowed" and redirected to tomcat's logger. this works for me, and the output ends up in the localhost_ log file Filip My webapp has its own self-contained log4j jar and configuration files and logs everything via the Console appender. I see all the log output in the stdout (as expected when swallowOutput is false), however, when I set swallowOuptut to true, only my filters' log statements are swallowed; the rest are still displayed on the console. I've tried looking through the Tomcat code to see if I can find where/how this is happening, but that portion of things seems to be way over my head. Any thoughts? Thanks, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput not working properly?
Hi Martin,
> 3 main items for Log4J are##CONSOLE# A1 uses
> PatternLayout.log4j.appender.A1.layout=org.apache.log4j.PatternLayoutlog4j.appender.A1.layout.ConversionPattern=%-4r
>
> [%t] %-5p %c %x - %m%n# A1 is set to be a
> Appender.log4j.appender.A1=org.apache.log4j.ConsoleAppender# Set root
> logger level to DEBUG and its only appender to A1.log4j.rootLogger=DEBUG,
> A1#ROLLING FILE APPENDERlog4j.rootLogger=debug, stdout,
> Rlog4j.appender.stdout=org.apache.log4j.ConsoleAppenderlog4j.appender.stdout.layout=org.apache.log4j.PatternLayout#
>
> Pattern to output the caller's file name and line
> number.log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) -
> %m%nlog4j.appender.R=org.apache.log4j.RollingFileAppenderlog4j.appender.R.File=example.loglog4j.appender.R.MaxFileSize=100KB#
>
> Keep one backup
> filelog4j.appender.R.MaxBackupIndex=1log4j.appender.R.layout=org.apache.log4j.PatternLayoutlog4j.appender.R.layout.ConversionPattern=%p
>
> %t %c - %m%n
> http://logging.apache.org/log4j/1.2/manual.html
>
> http://tomcat.apache.org/tomcat-5.5-doc/logging.html
> says the above log4k.properties goes to $TOMCAT_HOME/commons/classes
> folder
> also log4j.jar and commons-logging-x.y.z.jar go into common/lib folder
>
> make sure you use the level specified log.debug("statement") will display
> when debug level is on
Thanks for the input, but I think I might not have made myself clear in my
original posting.
At this point I have given up getting Tomcat to work properly with Log4j
(see my other thread about JULI and Log4j for details). So I have reverted
to using JULI with Tomcat. That is fine.
My problem now relates to using the swallowOutput parameter in the context
element. It doens't seem to be working properly. My webapp is properly
using log4j. Tomcat is using JULI. The swallowOutput seems to redirect
only some of the webapp's logs to the JULI specified file - not all. In
fact, from what I can tell, it seems as though only the logs generated by
Filters are swallowed. The rest of the logs generated by the rest of my
webapp classes remain displayed on StdOut.
Don't know where to start looking or how to start looking to debug this
problem.
Any thoughts?
Thanks,
Eric
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput not working properly?
"Filip Hanik - Dev Lists" wrote in message news:4a84706e.2040...@hanik.com... > Tomcat doesn't use log4j in v6 in its standard distribution. You have to > build an adapter for that I don't understand at all. Can you please clarify? All I am trying to accomplish is have the stdout from my webapp "swallowed" and redirected to tomcat's logger. My webapp has its own self-contained log4j jar and configuration files and logs everything via the Console appender. I see all the log output in the stdout (as expected when swallowOutput is false), however, when I set swallowOuptut to true, only my filters' log statements are swallowed; the rest are still displayed on the console. I've tried looking through the Tomcat code to see if I can find where/how this is happening, but that portion of things seems to be way over my head. Any thoughts? Thanks, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput not working properly?
Tomcat doesn't use log4j in v6 in its standard distribution. You have to
build an adapter for that
Filip
On 08/13/2009 12:49 PM, Eric B. wrote:
Hi,
I'm trying to get Tomcat to log the output each context individually in its
own log file.
I tried using the swallowOutput in my object definition, but am
getting some really weird results from it. My webapp uses log4j to do its
logging with its own log4j.xml file within the webapp, and all log4j's
output is
defined as using the org.apache.log4j.ConsoleAppender.
My context.xml file is:
conf/Catalina/localhost/ROOT.xml:
${catalina.base}/conf/logging.properties:
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4admin.org.apach\e.juli.FileHandler,
5host-manager.org.apache.juli.FileHandler,
6root.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
6root.org.apache.juli.FileHandler.level = ALL
6root.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
6root.org.apache.juli.FileHandler.prefix = root.
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].level =
ALL
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].handlers =
6root.org.apache.juli.FileHandler
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.
It is extremely confusing; there doesn't seem to be any pattern. Some
webapp logs go to root.log, other still are displayed on stdout, and
therefore in catalina.out. Like I said, all log msgs in the webapp use the
same log4j ConsoleAppender.
I'm running Tomcat 6.0.18. I searched through the changelog for 6.0.19 and
6.0.20 and don't see anything that relates to this, so I am wondering if
this is an issue that still exists.
Is my configuration wrong?
Thanks,
Eric
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput not working properly?
"Eric B." wrote in message news:h61n91$r1...@ger.gmane.org... > I tried using the swallowOutput in my object definition, but am > getting some really weird results from it. My webapp uses log4j to do its > logging with its own log4j.xml file within the webapp, and all log4j's > output is > defined as using the org.apache.log4j.ConsoleAppender. > > 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. > > It is extremely confusing; there doesn't seem to be any pattern. Some > webapp logs go to root.log, other still are displayed on stdout, and > therefore in catalina.out. Like I said, all log msgs in the webapp use > the same log4j ConsoleAppender. I've dug around a little more, and I seem to see a bit of a pattern. Struts2 logs seem to be swallowed (my logs entries from org.apache.struts2.config.BeanSelectionProvider are in the root.log file), and loggers that are defined in my webapp's filters seem to be swallowed as well. However, nothing from the webapp itself. I found a thread from mid June 2009 about this and timing between when Tomcat replaces the System.out and System.err streams, so I manually launched my webapp from the manager once Tomcat was up and initialized, but it made no difference either. And my results seem to be repeatable; evertime I restart Tomcat and/or my webapp, it is the same filters that manage to get swallowed, but nothing else from the webapp. Any thoughts, suggestions, advice? Thanks, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
