Wednesday, November 15, 2017

Re: Deploying symbolMaps in a production build

Symbol maps are distinct from source maps, the serve different purposes. Sourcemaps, when deployed with your actual source, allow the browser to ask the server for your Java source, so you can see if when you debug - this may not be something most production applications want their customers to be able to find.

In contrast, symbol maps are used by the server, so when the client sends the server a stack trace, it can figure out what that stack trace should have looked like in Java (see This will work without enabling sourcemaps.

The "// #sourceURL=" is used to say to the browser "pretend that this string you are eval()ing is actually a file with this name and path". If used in conjunction with sourcemaps, then if you have deployed sourcemaps, viewing the source in your browser will show all Java classes.

To turn on production sourcemaps, add this to your .gwt.xml file (assuming the CrossSiteIframeLinker, which it appears you are using) if you just want them always on (assumes one permutation):

  <set-configuration-property name="includeSourceMapUrl" value="true"/>

If you have more than one permutation, you'll want to set up a pattern in here, based on the docs in CrossSiteIframeLinker.gwt.xml:
     - Determines whether the GWT compiler generates cache.js files
     - that end with a comment pointing to a sourcemap file, to support source-level
     - debugging in browsers.
     - Specification:
     - Takes on the following values:
     - if "false":
     -   no sourcemap URL declarations are included at the end of the primary fragment script
     - if "true":
     -    a relative URL to the standard sourcemap for the primary fragment is included.
     - Otherwise:
     -   The value is assumed to be a custom URL. The following tokens will be substituted:
     -   __MODULE__ is replaced with the module name
     -   __FRAGMENT__ is replaced with the fragment id, which will be 0 for the initial fragment.
     -   __HASH__ is replaced with the strong name of the fragment.

This only adds the missing "// #sourceMappingURL=" to your output, but the sourcemaps has to actually be there for you to use it, and in the right place - using those custom URL features will help you change where it goes.

Keep in mind that your webserver will not serve any content in WEB-INF/, so you'll need to build those somewhere else for the client to see it (see the -deploy flag). You would also need to add all of your java sources, and they are also expected to be found in the same directory as the sourcemap file, and remember that this may allow your users to see the app's sources.

On Tuesday, November 14, 2017 at 7:34:40 AM UTC-6, AJ wrote:
I have an issue that only manifests in a deployed GWT application and so am trying to enable source maps in the production build.

I have added...

    <add-linker name="xsiframe" />
    <set-property name="compiler.useSourceMaps" value="true"/> the project.ui.xml file and have passed -saveSource to the compiler

In my war I see the WEB-INF/deploy/ProjectName/symbolMaps folder
 containing 1A2B3C.symbolMap and 1A2B3C_sourceMap0.json

My understanding is that I need to have the following comment at the bottom of the various generated javascript files which are pulled in by the bootstrap code
//# sourceMappingURL=myUrl

so I should see that at the bottom of 1A2B3C.cache.js found in the project folder of the war (same folder as myProject.nocache.js)

What I see at the end of that file is...

//# sourceURL=Utmc-0.js

... and this is what is delivered in chrome devtools when I try to find the source

Has anyone else tried this and, if so, what am I missing?

You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
For more options, visit

No comments:

Post a Comment