Debugging a Java program running from Tomcat (JSP)

I don't know why I never found myself having to use a debugger to step through my program and see what was going on, probably because I'm used to using interpreted languages such as PHP where it becomes very easy to add debugging code (print_r) and see changes live.

However with this new Java project I feel like I must learn the correct ways of debugging.

So this program, that I didn't write, runs on Tomcat and uses basic JSPs. The issue is that when I try to access a specific JSP page it throws an exception and gives me the stacktrace of what happened:

org.apache.jasper.JasperException: java.lang.NullPointerException
    org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:503)
    org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
    org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:363)
    org.apache.jasper.servlet.JspServlet.service(JspServlet.java:306)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
    org.sgrp.singer.filters.SingerLoginFilter.doFilter(SingerLoginFilter.java:128)

How would I step through my program using a tool such as JDB? I can't really step through a specific class because I need to mimic what my JSP is doing... I would like to do this through the command-line, without using a开发者_高级运维n IDE.

First, java has to be started with certain parameters to plugin a debugger:

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

are the parameters used for our purpose. Afterwards, you use your IDE and connect the debugger remotely. You set a breakpoint to a piece of code (please make sure that the local files and the remote program are exactly the same revision) and generate the error. You can set breakpoints to uncaught exceptions as well.

As a hint: You can alter your referenced error-catching-JSP (error.jsp for us) to display not only the stacktrace of the caught exception (ex.getStracktrace), but also the causing stacktrace (ex.getCause().getStacktrace()). This might help identify higher level exception causes.

Edit: I'm sorry, without an IDE this is an information overflow that might not be possible for a human to do. Tomcat applications are complex on an architectural level, switching between a number of different classes for the easiest requests.

An alternative solution that may be easier to use than hooking a debugger to Tomcat:

First, take a look at the call stack. At the bottom, you'll see your class named org.sgrp.singer.filters.SingerLoginFilter. The problem lies here, at line 128 of method doFilter.

The first line says org.apache.jasper.JasperException: java.lang.NullPointerException. That means you've used an object whose value is null at line 128 of mentioned class.

Check out that code to find out what could be wrong. Also, add some print/logging statements to your code.

Debugging should be your last resort. You can gather a lot of information just by looking at your stack trace.

JDB could be used, it wouldn't be my first choice though.

Here is a good explanation how to use it: http://www.javaworld.com/javaworld/javaqa/2000-06/04-qa-0623-jdb.html

You need to remember to include debug information when you compile your files and set up the Tomcat so you are able to connect to it, this is the string, as mentioned by other post:

-Xdebug -Xnoagent -Djava.compiler=NONE-Xrunjdwp:server=y, transport=dt_socket,address=8000,suspend=y

8000 can be replaced by any other numerical value. It basicaly tells jvm to listen on that port for a debugger.

What will happen now, is tomcat will start but suspend itself and wait for a debugger to attach before proceeding.

Start JDB and attach:

jdb -attach localhost:8000

in here, localhost can be replaced by where tomcat is running if it's running on a different machine and 8000 can be replaced with whatever port you set jvm in tomcat.

Now you can debug, you can see the debug instructions if you type help in jdb.

I have always used eclipse debugger, either running tomcat within eclipse or connecting eclipse to a separate, but local to eclipse, jboss server.

Works like a dream, no need to change jvm settings or anything.