Home Java Running GWT Super Dev Mode for remote server

Running GWT Super Dev Mode for remote server

by admin

Our JEE application made the GWT version jump from 1.7 immediately to 2.6.1. Once upon a time there was a little tinkering to set up the ability to debug the client side in the IntelliJ Idea development environment. Debugging consists of being able to put breakpoints (breakpoints) in the Java code, but hit them from the browser JavaScript generated by GWT from the Java code. After updating the GWT version, the old debugging startup configuration stopped working, and I had to get acquainted with GWT Super Dev Mode (SDM). After that "introduction" I realized that the aforementioned "dancing" was actually an extremely simple and straightforward setup, at least compared to SDM. Hopefully, this article will save someone a couple of days of wandering around the forums and get rid of a few new gray hairs. In this article I will tell about my experience with running SDM in the following environment: IntelliJ Idea 14, JBoss EAP 6, GWT 2.6.1 with GWT RPC in the project, Chrome browser. Even though the release of Idea 14 reported enhancements 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 have any effect on the SDM setup. About GWT versions: for 2.6.0 it works almost identically, same for 2.7.0 (I have not checked it myself, I read it on the web while doing research).

The general part

The good old debugging mode is now practically not supported in GWT, its place has been taken by Super Dev Mode. This mode involves running a specific application server, the so-called Code Server, which is responsible for deploying the source Java code and mapping it to JavaScript. Most sources describe deploying your application under Code Server and working directly with it. Since I am using IntelliJ Idea as my development environment, it is assumed that my application will be run and deployed directly in it. But in JEE developers usually try to work with environment which is close to industrial one as possible and it is nonsense to run Idea under industrial server. So, we face a dilemma: the Code Server is running in the development environment, and the application server is running on a separate computer – how to "make friends"? In principle, there is all the information we need on the web, but it is scattered and contradictory and there is even a StackOverflow answer, which has a lot of "pluses" but is wrong. Based on these facts, and realizing how difficult it is to run SDM in general, I decided to write this guide.

Refinements and adjustment

  • In all .gwt.xml add a line
    <add-linker name="xsiframe"/>

    Without it SDM will not work. In GWT 2.7 this is configured by default, so you don’t need to add it. You can also build to a production server with this parameter.

  • In all .gwt.xml, add the line
    <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 a production server, it is advisable to remove/comment this parameter.

  • For GWT version 2.6.0, in all .gwt.xml add the line
    <set-configuration-property name="devModeRedirectEnabled" value="true"/>
  • If you use GWT RPC, then in all of the RemoteServiceServlet descendants you should override the getCodeServerPolicyUrl I did it like this :
    /*** The method is redefined exclusively for debugging in GWT SDM mode. In order to make the server work in* GWT SDM debugging mode, you must specify the system properties gwt.codeserver.port(a standard GWT SDM property) and* gwt.codeserver.host(specific property of our System). After specifying these properties and restarting the server* gwt.rpc files will be pulled from the specified host where GWT Code Server is to run. This* is required to ensure that the client being debugged has the same versions of compiled types as the server.* WARNING: Do not allow these properties to be specified on industrial servers!*/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 method comment, you can see that the GWT developers only provided the option to specify the port number where the Code Server resides, but not the network address, i.e., they apparently did not assume that the application server and the Code Server could 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 JVM startup parameters -Dgwt.codeserver.host= -D=gwt.codeserver.port=, or by using tools specific to your server. In JBoss EAP, you can add a block to the configuration file (standalone*.xml, domain.xml) for this <system-properties> with <property name=""value=""/> in it. Make sure you have access from the application server to the specified address and port after starting Code Server (telnet "fails").
  • Add a new GWT Configuration to Idea and specify in it :
  • Enable "Use Super Dev Mode" checkbox
  • If after starting debugging you see "log4j:ERROR" in the log, in "VM options" add -Dlog4j.ignoreTCL=true You may not need this, I had some GWT collisions with the project logging libraries
  • In "Dev Mode parameters" add -bindAddress where you specify the IP address of the Code Server (the developer’s computer). By default, CodeServer listens to localhost or, but if the application server is on another computer, it will not be able to access CodeServer at these addresses, so you should tell CodeServer to listen to an externally accessible address.
  • GWT 2.6.1 has a glitch that occurs when running CodeServer in Idea (probably not when running independently of the development environment). The problem is that there is an attempt to recreate temporary file folders when the application is deployed, which ends in an error, causing the CodeServer to stop. To solve this problem, I had to patch the gwt-codeserver.jar library, where in the CompileDir class I commented out the line
    throw new UnableToCompleteException();

    at the very end of the file. The sources are in gwt-codeserver.jar itself; pull out the .java, modify, compile, throw the .class back into gwt-codeserver.jar. Only the developer needs the library, and it has nothing to do on the production server (and on the test server too), so there’s no reason to worry about this 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 Chrome
    • Move "Dev Mode On" and "Dev Mode Off" buttons to "Favorites" of your browser
    • Our application is set up so that when you log into the System, it opens a window with the browser controls, including "Favorites", turned off. If you do the same, change your HTML so that "Dev Mode On" and "Dev Mode Off" are available on the client side
    • Open the client window in the browser and click on "Dev Mode On", then press the "Compile" button
    • Wait while Code Server completes compilation. After that the page will be reloaded.
    • After the page reloads by pressing F12 in Chrome, open the standard developer tools, where you open the Sources tab. In the tree on the left (the Sources tab inside the Sources tab), you can see that there are currently resources downloaded not only from the main application server, but from CodeServer as well. Press CTRL+P, look for the Java class we’re going to debug, put a Breakpoint in it.

    WARNING: When you finish debugging in GWT SDM mode, roll back the changes in .gwt.xml ("devModeUrlWhitelistRegexp") and rebuild the application!

    You may also like