Running GWT Super Dev Mode for a Remote Server
- Tutorial
Our JEE application made a jump in the GWT version from 1.7 immediately to 2.6.1. Once upon a time there were small dances with a tambourine in order to configure the ability to debug the client part in the IntelliJ Idea development environment. Debugging consists in the ability to set breakpoints (breakpoints) in the Java code, but to get into them from the browser JavaScript generated by the GWT from the Java code. After updating the GWT version, the old debug launch configuration stopped working, and I had to get to know GWT Super Dev Mode (SDM). After this “acquaintance”, I realized that the above-mentioned “dances” were actually an extremely simple and understandable setting, at least in comparison with SDM. I hope this article helps someone a lot to save a couple of days of wandering around the forums and save a few new gray hair. In this article, I will tell you about the experience of launching SDM mode in the following environment: IntelliJ Idea 14, JBoss EAP 6, GWT 2.6.1 using the GWT RPC project in the Chrome browser. Despite the fact that with the release of Idea 14 they reported about improvements regarding debugging in GWT, I think that for version 13 all of the following is also applicable. The application server used is also unlikely to somehow affect SDM configuration. As for the versions of GWT: for 2.6.0 almost one-to-one is applicable, the same applies to 2.7.0 (I did not check it myself, I read it on the Web during the research). The application server used is also unlikely to somehow affect SDM configuration. As for the versions of GWT: for 2.6.0 almost one-to-one is applicable, the same applies to 2.7.0 (I did not check it myself, I read it on the Web during the research). The application server used is also unlikely to somehow affect SDM configuration. As for the versions of GWT: for 2.6.0 almost one-to-one is applicable, the same applies to 2.7.0 (I did not check it myself, I read it on the Web during the research).
The good old debugging mode is now practically not supported in GWT, Super Dev Mode took its place. This mode involves launching a specific application server, the so-called Code Server, which is responsible for deploying the source Java code and comparing it with JavaScript. Most sources describe how to deploy your application running Code Server and work directly with it. Because Since I use IntelliJ Idea as a development environment, it is assumed that my application will be launched and deployed directly in it. But in JEE, developers usually try to work with an environment as close as possible to the industrial one, and launching an industrial server “from under Idea” is nonsense. Thus, a dilemma arises: Code Server is running in a development environment, and the application server is running on a separate computer - how to "make friends" with them? In principle, the Web has all the necessary information, but it is scattered, contradictory, and there is even an answer to StackOverflow, which has many "advantages", but at the same time incorrect. Based on these facts, as well as understanding how difficult it is to run SDM in general, I decided to write this guide.
ATTENTION! After debugging in GWT SDM mode, roll back the changes to .gwt.xml ("devModeUrlWhitelistRegexp") and rebuild the application!
a common part
The good old debugging mode is now practically not supported in GWT, Super Dev Mode took its place. This mode involves launching a specific application server, the so-called Code Server, which is responsible for deploying the source Java code and comparing it with JavaScript. Most sources describe how to deploy your application running Code Server and work directly with it. Because Since I use IntelliJ Idea as a development environment, it is assumed that my application will be launched and deployed directly in it. But in JEE, developers usually try to work with an environment as close as possible to the industrial one, and launching an industrial server “from under Idea” is nonsense. Thus, a dilemma arises: Code Server is running in a development environment, and the application server is running on a separate computer - how to "make friends" with them? In principle, the Web has all the necessary information, but it is scattered, contradictory, and there is even an answer to StackOverflow, which has many "advantages", but at the same time incorrect. Based on these facts, as well as understanding how difficult it is to run SDM in general, I decided to write this guide.
Improvements and customization
- Add a line to all .gwt.xml
<add-linker name="xsiframe"/>
Without it, SDM will not work. In GWT 2.7, this is configured by default, so you can not add it. You can also build with this parameter on an industrial server. - Add a line to all .gwt.xml
<set-configuration-property name="devModeUrlWhitelistRegexp" value="http://192\.168\.1\.1(:\d+)?/.*" />
In it, specify the IP address of the developer's computer on which Code Server will be launched. When building an application for an industrial server, it is advisable to remove / comment out this parameter. - For GWT version 2.6.0 add a line to all .gwt.xml
<set-configuration-property name="devModeRedirectEnabled" value="true"/> - If you use GWT RPC, then in all descendants of RemoteServiceServlet, you must override the getCodeServerPolicyUrl method . I did it like this:
/** * Метод переопределен исключительно для отладки в режиме GWT SDM. Для того, чтобы сервер заработал в режиме * отладки GWT SDM следует указать системные свойства gwt.codeserver.port (стандартное св-во GWT SDM) и * gwt.codeserver.host (специфическое св-во нашей Системы). После указания этих свойств и перезапуска сервера * файлы .gwt.rpc будут подтягиваться с указанного хоста, на котором должен быть запущен GWT Code Server. Это * требуется для того, чтобы отлаживаемый клиент имел те же версии скомпилированных типов, что и сервер. * ВНИМАНИЕ! Не допускать указание этих свойств на промышленных серверах! */ protected String getCodeServerPolicyUrl(String strongName) { String port = System.getProperty("gwt.codeserver.port"); String host = System.getProperty("gwt.codeserver.host"); if (port == null || port.trim().isEmpty() || host == null || host.trim().isEmpty()) { return super.getCodeServerPolicyUrl(strongName); } return "http://" + host + ":" + port + "/policies/" + strongName + ".gwt.rpc"; }
From the contents of the commentary on the method, it can be understood that the GWT developers provided the ability to specify only the port number on which the Code Server is located, but not the network address, i.e., apparently, they did not assume that the application server and Code Server be different computers. - Specify the values of the system properties " gwt.codeserver.host " and " gwt.codeserver.port " for the test application server. This can be done by specifying the start parameters JVM -Dgwt.codeserver.host = -D = gwt.codeserver.port =, or using specific tools for your server. In JBoss EAP, for this, you can add the <system-properties> block with <property name = "" value = "" /> to it in the configuration file (standalone * .xml, domain.xml) . Make sure that after starting Code Server, you have access from the application server to the specified address and port (telnet “fails”).
- Add a new GWT Configuration to Idea and specify in it:
- Enable checkbox “Use Super Dev Mode”
- If after starting the debugging you will see “log4j: ERROR” in the log, then in the “VM options” add -Dlog4j.ignoreTCL = true . You may not need this; I had some kind of GWT conflict with the project logging libraries
- In “Dev Mode parameters” add -bindAddress 192.168.1.1 , where to specify the IP address of the Code Server (the computer of the developer). By default, CodeServer listens on localhost or 127.0.0.1, but if the application server is on another computer, it will not be able to access CodeServer at such addresses, so you should tell CodeServer to listen on an address that is accessible from the outside.
- GWT 2.6.1 has a glitch that manifests itself when CodeServer starts up in Idea (it may not exist if it is independent of the development environment). The problem is that an attempt is made to re-create folders for temporary files when deploying the application, which fails with an error that causes CodeServer to stop. To solve this problem I had to patch the gwt-codeserver.jar library, in which I commented out a line in the CompileDir class
thrownew UnableToCompleteException();
at the very end of the file. Sources are in gwt-codeserver.jar itself; pull out .java, modify, compile, throw .class back into gwt-codeserver.jar. Only the developer needs the library, and on the industrial server (and on the test one too) she has nothing to do, so there is no reason to worry about such unceremonious treatment.
Launch
- Rebuild the application and start your server
- Run CodeServer (GWT Configuration) in Debug mode
- Open the address specified in the CodeServer log in the Chrome browser (http://192.168.1.1:9876/)
- Move the Dev Mode On and Dev Mode Off buttons to the “Favorites” of the browser
- Our application is configured so that when you enter the System, a window opens with the browser controls disabled, incl. "Favorites". If you do the same, then change your HTML so that “Dev Mode On” and “Dev Mode Off” are available in the client side
- Open the client part in the browser and click “Dev Mode On”, then press the “Compile” button
- We are waiting for the compilation to be completed on the side of Code Server. After that, the page will reload.
- After reloading the page by pressing F12 in Chrome, we open the standard developer tools, in which we open the Sources tab. In the tree on the left (the Sources tab inside the Sources tab) you can see that at the moment there are resources downloaded not only from the main application server, but also from CodeServer. We press CTRL + P, look for the Java class that we are going to debug, put Breakpoint in it.
ATTENTION! After debugging in GWT SDM mode, roll back the changes to .gwt.xml ("devModeUrlWhitelistRegexp") and rebuild the application!