Несмотря на то, что я пишу на Java уже 2 месяца (о да, это срок :) ), я ни разу не запускал remote debugger. При разработке на GWT этого делать и не нужно — оно как-то само всё это делает. :) Но вот настала весна, моё GWT приложения распустилось, и хочет, чтобы я его выложил на сервер. Но вдруг выяснилось, что просто так оно работать не захотело. А почему, я понять не могу. И значит мне нужен дебагер.
Принцип работы наверное любого удалённого отладчика (remote debugger) прост — контейнер (это может быть и какой-либо сервлет-контейнер, и php-интерпритатор. Полагаю, что интерпритаторы Ruby, Perl, Python работают аналогичным образом), который выполняет приложение настраивается таким образом, что при запуске приложения он либо начинал слушать определенный порт, либо сам пытался коннектиться куда-либо.
Для того, чтобы заставить Java-машину включить отладчик и повесить его на определённый порт, нужно указать в командной строке следующие параметры:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
Для того, чтобы tomcat запускался всегда с этими параметрами, вам придётся поправить старт-скрипт. В моём случае это /etc/init.d/tomcat5.5.
После того, как вы перезапустите tomcat при помощи вашего исправленого скрипта, вы можете проверить, запустился ли дебагер, попытавшись подключиться к указаному вами порту. В моём случае это порт 8000:
telnet localhost 8000
Если подключиться не удалось, значит вы что-то сделали не так. Если вам всё же повезло, то вы можете смело открывать свою любимую IDE, конфигурировать её на работу с вашей Java-машиной (я уверен, что теперь вы сможете делать это более вдумчиво) и наслаждаться работой.
P.S. При помощи дебагера мне удалось выяснить что проблема была в вылетающем исключении на стадии сериализации RPC-ответа. Следующие сутки я потратил на то, чтобы разобраться почему всё же этот эксепшен (java.security.AccessControlException) случается. Оказалось, что tomcat умеет ограничивать права выполняемых сервлетов, и в моём случае он ограничивал раже доступ к рефлекшену сериализуемых объектов. Думаю, что система безопасности tomcat — это тема для отдельного топика, которым я когда-нибудь разрожусь.
Принцип работы наверное любого удалённого отладчика (remote debugger) прост — контейнер (это может быть и какой-либо сервлет-контейнер, и php-интерпритатор. Полагаю, что интерпритаторы Ruby, Perl, Python работают аналогичным образом), который выполняет приложение настраивается таким образом, что при запуске приложения он либо начинал слушать определенный порт, либо сам пытался коннектиться куда-либо.
Для того, чтобы заставить Java-машину включить отладчик и повесить его на определённый порт, нужно указать в командной строке следующие параметры:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
Для того, чтобы tomcat запускался всегда с этими параметрами, вам придётся поправить старт-скрипт. В моём случае это /etc/init.d/tomcat5.5.
После того, как вы перезапустите tomcat при помощи вашего исправленого скрипта, вы можете проверить, запустился ли дебагер, попытавшись подключиться к указаному вами порту. В моём случае это порт 8000:
telnet localhost 8000
Если подключиться не удалось, значит вы что-то сделали не так. Если вам всё же повезло, то вы можете смело открывать свою любимую IDE, конфигурировать её на работу с вашей Java-машиной (я уверен, что теперь вы сможете делать это более вдумчиво) и наслаждаться работой.
P.S. При помощи дебагера мне удалось выяснить что проблема была в вылетающем исключении на стадии сериализации RPC-ответа. Следующие сутки я потратил на то, чтобы разобраться почему всё же этот эксепшен (java.security.AccessControlException) случается. Оказалось, что tomcat умеет ограничивать права выполняемых сервлетов, и в моём случае он ограничивал раже доступ к рефлекшену сериализуемых объектов. Думаю, что система безопасности tomcat — это тема для отдельного топика, которым я когда-нибудь разрожусь.
