System.out.printlin on Tomcat

Hello

When I code a System.out.println in a Java class and then execute that class on a Tomcat server in an IE browser, where does the System.out.println write to? Basically, where can I view the information I am trying to display? I looked in the Tomcat Server administrative tool and I did not see any helpful information.

Thanks in advance for the help.

Assuming Windows, if running Tomcat as a service…maybe the Windows event viewer? (I don’t run it as a service, so the println messages come up in the dos window that opens when tomcat is running)

Also, you can capture the output in your logs by using ‘swallowOutput=true’ in the Context tag for your application.

The best option of all is to use commons.logging / log4j

I’m not sure but try checking %tomcat%\logs\stdout_.log and stderr_.log , for System.out.println and System.err.println respectively. I haven’t actually tested this but that’s my best guess, or use log4j as suggested by Rushiku, I’ve worked with it before, it’s pretty good for logging.

Don’t know if it helps but in Resin there is a stdout.log and a stderr.log file for when you are running on a non Windows system but as rush mentioned I watch the DOS window for these when I’m testing.

Also try looking for catalina.out in the logs directory.

but have a look at log4j or other logging packages. That way you’ll know for sure where your output is going.

Jurn

Thank you all very much for the responses.

Just to clarify here, Tomcat is kicked of by the system each day since we have other applications that are using it (so there is not a handy display console I could view). Based on this, here is what I have found with all of you help.

The stdout.log file did contain the System.out.println statements but it also displayed many other log messages making it somewhat difficult to view. This can be found in the Drive:\Program Files\Apache Software Foundation\Tomcat 5.0\logs directory.

So I set Swallow Output to true and this then produces a file called vision-pi_host.DATE.txt. The only thing displayed in this file is the System.out.println’s so it made it very easy to view.

The reason I wanted to see this is to just assist me in development. A lot of times, I like to add informal display (System.out.println) statements just so I can see the flow of the code, making sure the code works as I thought it should work. But while reading all the posts, it sounds like some people have log statements in there all of the time. Why would an application want log statements in an production environment?

Based on my question above is why I did not install the log4j. This required installing a few files and then adding code which it sounded like that I would keep in the code. Since I did not plan on keeping my display statements, I went with the above approach.

I also found out that I could add a PrintWriter and then just display output right in the browser. This might also be helpful. Here is how I accomplished that.


response.setContentType("text/html");
PrintWriter writer = response.getWriter();

writer.println("<html>");
writer.println("<head>");
writer.println("<title>Test DB Connection </title>");
writer.println("</head>");

writer.println("<body bgcolor=white>");
writer.println("Test");

writer.println("</body>");
writer.println("</html>");
		
writer.flush();
writer.close();

If you have any thoughts, I would like to hear them since I am doing this to learn as much as I can. I am new to the web world (working only about 3 months in a web support group).

Thanks

Logging can be a heck of a challenge to setup the first time (it was for me anyway), I’d suggest putting up the money for a book.

Anyway, the nice thing about log4j logging, or commons for that matter, is that you specify the ‘logging level’ on each log statement. log.debug, or log.error for example.

Then, in the logging config file, you specify what level (and from which classes or packages if you want) you want to see. During develoment I run full out debug level, then when it goes into production I knock it down to info, or maybe error, either of which filter out all the debug level messages.

If something goes wrong, I start by turning debug back on and all my debug logging statements are logged again, meaning: I don’t have to go back and rewrite them, recompile and redeploy the app just to start debugging.

As to why you would want logs in a production environment, well, imagine yourself saying “Ummm, yes sir, Mr. Company President, the application does seem to have a problem, the thing is…we don’t have a clue as to what that problem might be because we don’t keep any logs…yessir, I understand…but if it was working, you would see that it runs faster with no logging. When will it be fixed? We don’t know, we don’t know what’s wrong because we don’t keep any logs”

With good logging, you can usually pin-point and fix a problem in a few minutes, and be a hero, rather than a zero.

Your last point is a very tough point to argue. Maybe I should spend the time it takes to setup and better understand logging. Thanks… I appreciate your time and thoughts.