March 8, 2009 at 07:44Debugging Java Servlets
Despite the fact that I have been writing in Java for 2 months (oh yes, this is a deadline :)), I have never run remote debugger. When developing on GWT, you do not need to do this - it somehow does it all by itself. :) But now spring has come, my GWT application has blossomed, and wants me to post it on the server. But suddenly it turned out that it just didn’t want to work. And why, I can’t understand. And so I need a debugger.
The principle of operation of probably any remote debugger is simple - a container (it can be either a servlet container or a php interpreter. I believe that Ruby, Perl, Python interpreters work in the same way), which runs the application and is configured this way that when starting the application, he either started listening to a specific port, or he tried to connect somewhere.
In order to force the Java machine to turn on the debugger and hang it on a specific port, you need to specify the following parameters on the command line:
-Xdebug -Xrunjdwp: transport = dt_socket, address = 8000, server = y, suspend = n
In order to tomcat It always started with these parameters, you have to fix the start script. In my case it is /etc/init.d/tomcat5.5.
After you restart tomcat using your fixed script, you can check if the debugger started by trying to connect to the port you specified. In my case, this is port 8000:
telnet localhost 8000
If you can’t connect, it means you did something wrong. If you are lucky, then you can safely open your favorite IDE, configure it to work with your Java machine (I'm sure that now you can do it more thoughtfully) and enjoy the work.
PS With the help of the debugger, I was able to find out that the problem was an outgoing exception at the serialization stage of the RPC response. The next day I spent trying to figure out why, nevertheless, this execution ( java.security.AccessControlException ) happens. It turned out that tomcat is able to restrict the rights of servlets that are executed, and in my case it restricted access to reflexion of serializable objects. I think that the tomcat security system is a topic for a separate topic, which I will ever get wild.
The principle of operation of probably any remote debugger is simple - a container (it can be either a servlet container or a php interpreter. I believe that Ruby, Perl, Python interpreters work in the same way), which runs the application and is configured this way that when starting the application, he either started listening to a specific port, or he tried to connect somewhere.
In order to force the Java machine to turn on the debugger and hang it on a specific port, you need to specify the following parameters on the command line:
-Xdebug -Xrunjdwp: transport = dt_socket, address = 8000, server = y, suspend = n
In order to tomcat It always started with these parameters, you have to fix the start script. In my case it is /etc/init.d/tomcat5.5.
After you restart tomcat using your fixed script, you can check if the debugger started by trying to connect to the port you specified. In my case, this is port 8000:
telnet localhost 8000
If you can’t connect, it means you did something wrong. If you are lucky, then you can safely open your favorite IDE, configure it to work with your Java machine (I'm sure that now you can do it more thoughtfully) and enjoy the work.
PS With the help of the debugger, I was able to find out that the problem was an outgoing exception at the serialization stage of the RPC response. The next day I spent trying to figure out why, nevertheless, this execution ( java.security.AccessControlException ) happens. It turned out that tomcat is able to restrict the rights of servlets that are executed, and in my case it restricted access to reflexion of serializable objects. I think that the tomcat security system is a topic for a separate topic, which I will ever get wild.