Our JEE application jumped the GWT version from 1.7 to 2.6.1 right away. There used to be small dances with a tambourine in order to configure the ability to debug the client part in the IntelliJ Idea development environment. Debugging is the ability to set breakpoints in the Java code, but to get into them from browser-based JavaScript generated by GWT from Java code. After updating the GWT version, the old debugger launch configuration stopped working, and I had to get acquainted with the GWT Super Dev Mode (SDM). After this "acquaintance", I realized that the above-mentioned "dances" were in fact an extremely simple and understandable setting, at least in comparison with SDM. I hope that this article will help someone to save a couple of days of wandering around the forums and get rid of several new gray hair. In the article I will tell you about the experience of launching the SDM mode in the following environment: IntelliJ Idea 14, JBoss EAP 6, GWT 2.6.1 using GWT RPC in the project, Chrome browser. Despite the fact that, with the release of Idea 14, there were reports of improvements regarding debugging in GWT, I think that for version 13, everything described below also applies. The application server used is also unlikely to somehow affect the SDM configuration. As for the GWT versions: 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 in the course of research).
a common part
The good old debugging mode is now practically not supported in GWT, it was replaced by Super Dev Mode. This mode involves launching a specific application server, the so-called Code Server, which is responsible for deploying the original Java code and comparing it with JavaScript. Most sources describe the deployment of your Code Server application and working directly with it. Since I use IntelliJ Idea as my development environment, it is assumed that my application will be launched and deployed right in it. But in JEE, developers usually try to work with an environment as close as possible to the industrial environment, and the launch of the “from Idea” industrial server is nonsense. Thus, a dilemma arises: Code Server is running in the development environment, and the application server is running on a separate computer - how to make them friends? 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 “pluses”, but it is incorrect. Based on these facts, as well as understanding how difficult and in general it is to launch SDM, I decided to write this manual.
Improvements and configuration
- 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 collect with this parameter and on the 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 the Code Server will run. When building an application for an industrial server, it is desirable 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 the RemoteServiceServlet, override the getCodeServerPolicyUrl method. I did it like this:
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 content of the comment to the method, it can be understood that the GWT developers have provided the possibility of specifying 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 the Code Server can 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 of the JVM -Dgwt.codeserver.host = -D = gwt.codeserver.port =, or using tools specific to your server. In JBoss EAP, you can add a <system-properties> block with a <property name = "" value = "" /> in it to the configuration file (standalone * .xml, domain.xml). Make sure that after running the 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 indicate in it:
- Enable the checkbox "Use Super Dev Mode"
- If after debugging start you see “log4j: ERROR” in the log, then in “VM options” add -Dlog4j.ignoreTCL = true . You may not need this, I have some kind of collision between GWT and project logging libraries.
- In “Dev Mode parameters” add -bindAddress 192.168.1.1 , where specify the IP address of the Code Server (developer computer). By default, CodeServer listens to 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 specify CodeServer to listen to the address accessible from the outside.
- In GWT 2.6.1, there is a glitch that appears when you start CodeServer in Idea (it may not exist when the development environment is independent of the development environment). The problem is that an attempt is made to re-create folders for temporary files when the application is deployed, which ends 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 the line in the CompileDir class
throw new UnableToCompleteException();
at the very end of the file. The sources are in the gwt-codeserver.jar itself; we take out .java, we change, we compile, we throw .class back to gwt-codeserver.jar. The library is needed only by the developer, and on the industrial server (and on the test one as well) there is nothing for it to do, so there is no reason for concern about such an arrogant appeal.
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 log on to the System, a window opens with the browser controls turned off, incl. "Favorites". If you do the same, change your HTML so that “Dev Mode On” and “Dev Mode Off” are available in the client part.
- Open the client part in the browser and click "Dev Mode On", then click the "Compile" button
- We wait while on the side of Code Server compilation is completed. After this, the page will be reloaded.
- After reloading the page by pressing F12 in Chrome, we open 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, we are looking for a Java class that we are going to debug, set Breakpoint in it.
')
ATTENTION! Upon completion of debugging in GWT SDM mode, you should roll back the changes to .gwt.xml ("devModeUrlWhitelistRegexp") and rebuild the application!