Debugging Java Servlets
Despite the fact that I have been writing in Java for 2 months already (oh yes, this is the deadline :)), I have never launched the remote debugger. When developing on GWT, this is not necessary - it somehow does it all by itself. :) But spring has come, my GWT application has dissolved, and wants me to upload it to the server. But suddenly it turned out that it simply did not want to work. And why, I can not understand. And that means I need a debager.
The principle of operation of any remote debugger is probably simple - the container (it can be any servlet container and php interpreter. I suppose that Ruby, Perl, Python interpreters work in a similar way), which executes the application is configured in this way that when starting the application, he either started to listen to a certain 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 in the command line:
-Xdebug -Xrunjdwp: transport = dt_socket, address = 8000, server = y, suspend = n
')
In order for tomcat to always run with these parameters, you will have to fix the start script. In my case, this 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 failed to connect, then you did something wrong. If you are still lucky, then you can easily open your favorite IDE, configure it to work with your Java-machine (I am sure that now you can do it more thoughtfully) and enjoy the work.
PS With the help of the debugger, I managed to find out that the problem was in the outgoing exception at the stage of serialization of the RPC response. I spent the next day trying to figure out why this accession ( java.security.AccessControlException ) still happens. It turned out that tomcat is able to restrict the rights of servlets being executed, and in my case it limited the access to reflection objects to be serialized. I think that the tomcat security system is a topic for a separate topic, with which I will sometime get hung up.
The principle of operation of any remote debugger is probably simple - the container (it can be any servlet container and php interpreter. I suppose that Ruby, Perl, Python interpreters work in a similar way), which executes the application is configured in this way that when starting the application, he either started to listen to a certain 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 in the command line:
-Xdebug -Xrunjdwp: transport = dt_socket, address = 8000, server = y, suspend = n
')
In order for tomcat to always run with these parameters, you will have to fix the start script. In my case, this 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 failed to connect, then you did something wrong. If you are still lucky, then you can easily open your favorite IDE, configure it to work with your Java-machine (I am sure that now you can do it more thoughtfully) and enjoy the work.
PS With the help of the debugger, I managed to find out that the problem was in the outgoing exception at the stage of serialization of the RPC response. I spent the next day trying to figure out why this accession ( java.security.AccessControlException ) still happens. It turned out that tomcat is able to restrict the rights of servlets being executed, and in my case it limited the access to reflection objects to be serialized. I think that the tomcat security system is a topic for a separate topic, with which I will sometime get hung up.
Source: https://habr.com/ru/post/53846/
All Articles