Win a copy of Getting started with Java programming language this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Debugging war in tomcat  RSS feed

Al Grant
Posts: 10
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I have started learning war files and tomcat.

I have created a small war file which when you open a URL serves up a page, and on hitting submit button another page is opened as well as the data in the form serialized.

I am developing on windows with Intellij Idea and tomcat 8.5.4

I have been manually copying the war from Intlliej to webapps and starting the tomcat server with 'catalina jpda start' and connecting a remote debugger to tomcat which seems to work, because I get:

"Connected to server
Connected to the target VM, address 'localhost:8000', transport, socket"

On the console in Intellij.

The problem is that my System.out.println statements to not seem to print anything to either the CLI or to the debugger window in Intellij. I also dont seem to be able to inspect variables etc?

Anyone able to help?

Tim Holloway
Posts: 18504
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are using what is known as "Remote Debugging". IntelliJ (and most J2EE-friendly IDEs) has 2 ways to debug webapps.

The internal debugging mechanism launches Tomcat directly and is responsible for starting the debugging session.

Using Remote Debugging, you yourself are responsible for bringing up Tomcat (with debugging enabled) and connecting your debugger to it. Which you have done. Incidentally, Remote Debugging works with any JVM application, whether it's a webapp server or something else.

It's not recommended to use System.out or System.err in webapps because they effectively don't exist in non-Application environments, including webapp servers like Tomcat, Applets, and other more esoteric Java run environments. Instead, you should use a logger.

There's a primitive log write capability in the Servlet class, but it's so useless that most people don't even realize it's there. Even then, however, you'd still have the problem of not seeing the output where you expected.

That's because, while webapps don't really have a stdout/stderr, the JVM does and the catalina control scripts re-route them to the Tomcat console log, which is usually the catalina.out file in TOMCAT_HOME/logs.

So much for your tracing messages. Now for the variable inspection.

Java debuggers cannot look at variable while an application thread is running. The thread has to be paused. That can happen when an Exception is thrown, but for general debugging, you'd use a breakpoint,

For breakpoints to work properly, the source code that your debugger is using as a reference has to be in sync with the classes (WAR) that you are debugging. If it isn't, then the debugger (and you) can become confused. Fortunately, that shouldn't be a problem when you're debugging locally. Well, except for one "gotcha".

If you are actually building a .war file and copying it to TOMCAT_HOME/webapps, you may notice that once Tomcat is launched, a directory is also created in TOMCAT_HOME/webapps with the same base name as the WAR file. This is known as an "exploded WAR". Tomcat simply unzips your WAR into that directory. The "gotcha" is that the exploded WAR is what Tomcat actually runs and it does not  update that exploded WAR if you copy in a new WAR file. So to keep from getting out of sync, stop Tomcat and delete the exploded WAR directory and its children.

So, pick a spot where you want to nose around, set a breakpoint to that line (it must be executable code) using the IntelliJ debugger, fire up Tomcat and make a webpage request from your favorite web client (browser). Tomcat should process the request and when control flow hits the breakpoint line, execution will pause and you and inspect (and alter!) variables in the execution stack.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!