Deobfuscation configuration creates problems with multiple modules

[GoogleCodeExporter]

Does the issue occur in "quirks mode", "standards mode" or both? If you
don't know, does your HTML page contains a DOCTYPE declaration?
NA

What version of GWT are you using? 1.4.60? 2.0.4? Other?
2.2.0
What version of the gwt-log jar file or library file are you using?
3.1.0
What operating system(s) are you using? Windows? Linux? Mac?
Windows
Does the issue occur in web mode, development mode (formerly "hosted
mode"), both or don't know?
NA
What browser(s) do you use? Chrome, Firefox, IE, Safari, other?
NA
What is the browser version (if you know) from Help->About?
NA
What steps will reproduce the problem? Please attach sample code if you
can.
The problem lies with this piece

 <init-param>
    <param-name>symbolMaps</param-name>
    <!-- This value assumes a GWT compile with '-deploy war/WEB-INF/deploy/' -->
    <param-value>WEB-INF/deploy/yourmodulename/symbolMaps/</param-value>
  </init-param>

or the Guice equivalent,

        Map<String, String> params = new HashMap<String, String>();
        params.put("symbolMaps", "WEB-INF/deploy/yourmodulename/symbolMaps/");


We have defined a lighter developer module for use at most times (less compile 
combinations) and a production module (full blown compile). Since the location 
of symbolMaps is module-dependent, it is not possible to configure this in 
web.xml and/or guice module without adding some more complexity.

What is the expected output? What do you see instead?


Do you have a workaround?
The workaround would be to add a JVM parameter to specify what module is being 
used but I'd really like gwt-log to correct this instead.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 11 Mar 2011 at 5:35

[GoogleCodeExporter]

Sounds like you would like to be able to specify more than one location where 
symbol maps could be found. Is that right

Original comment by [email protected] on 11 Mar 2011 at 6:52

[GoogleCodeExporter]

yes but it should be able to detect which location to use based on what module 
has been loaded.

Original comment by [email protected] on 15 Mar 2011 at 7:08

[GoogleCodeExporter]

I have an additional problem related to this same issue. If you use maven with 
gwtmergewebxml, the servlet mapping are automatically generated, so I can't add 
this additional parameter. 
Expecifying this parameter on gwt.xml or any other place, on a module dependent 
maner,  would also solve this problem.

Original comment by [email protected] on 22 Mar 2011 at 1:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

As a workaround I configured my ant build to flatten all of the symbol map 
files from each module into a WEB-INF/symbolMaps directory to which I point 
gwt-log.

    <move todir="${war.dir}/WEB-INF/symbolMaps" flatten="true">
      <fileset dir="${build.web.dir}/bin.gwt">
        <include name="**/symbolMaps/*" />
      </fileset>
    </move>

Original comment by [email protected] on 24 Mar 2011 at 9:55

[GoogleCodeExporter]

Here's a suggested patch so that it'll take either the direct path to a 
module-specific folder or the parent folder for module-specific folders:


      protected InputStream getSymbolMapInputStream(String permutationStrongName)
          throws IOException {
          String fname = permutationStrongName + ".symbolMap";
        File symbolMap = new File(symbolMapsDirectory, fname);
          if(symbolMap.canRead())
              return new FileInputStream(symbolMap);

          for(File dir : symbolMapsDirectory.listFiles()) {
              if(dir.isDirectory()) {
                  symbolMap = new File(dir, fname);
                  if(symbolMap.canRead())
                      return new FileInputStream(symbolMap);
              }
          }
          throw new FileNotFoundException("No symbolMap file found for "+permutationStrongName);
      }

Original comment by [email protected] on 26 Apr 2011 at 11:16

[GoogleCodeExporter]

Also FWIW our app is broken into a few different modules so we also need this 
patch to fully benefit from the new capability of gwt-log.

Original comment by [email protected] on 26 Apr 2011 at 11:20

[GoogleCodeExporter]

The patch above is incorrect. It simply takes the first directory and that can 
correspond to a different module, resulting in incorrect deobfuscation.

What is needed is:
- on the server, specify with an init-param the "deploy" directory (the one 
that we pass to the GWT compiler). The structure of this directory is 
{deploy-dir}/{module-name}/symbolMaps. We have 2 variables here: {deploy-dir} 
(get this from init-param).
- pass the module name from the client side. This way, you know the value of 
the second variable {module-name} and can find the right symbolMaps directory.

Original comment by [email protected] on 20 Jun 2011 at 1:13

[GoogleCodeExporter]

The loop in the patch above only stops if it finds a matching symbol map file 
and since strong names ensure that no two symbol map files (even in different 
modules) have the same name I think this should work.  Was I wrong?  Did you 
try it?

Original comment by [email protected] on 20 Jun 2011 at 11:13

[GoogleCodeExporter]

Fixed in r615, released in version 3.1.3

Original comment by [email protected] on 20 Jun 2011 at 11:55

• Changed state: Fixed

[GoogleCodeExporter]

> The loop in the patch above only stops if it finds
> a matching symbol map file and since strong names
> ensure that no two symbol map files (even in
> different modules) have the same name I think
> this should work.  Was I wrong?
You are probably right. Only the code is not obvious and this is why I missed 
it. The code needs at least one comment about this.

Thanks for the patch. I believe many GWT projects will have multiple modules.

Original comment by [email protected] on 21 Jun 2011 at 7:16

[GoogleCodeExporter]

i reviewed changeset r615. Maybe I am missing something, somebody please 
explain how this will work

        for (StackTraceDeobfuscator deobf : deobfuscatorList) {
          deobfuscatedStackTrace = deobf.deobfuscateStackTrace(deobfuscatedStackTrace, permutationStrongName);
        }

seems you will just get the result from the last one?

Original comment by [email protected] on 22 Jun 2011 at 8:24

[GoogleCodeExporter]

I think he is assuming only one of them will do anything, or that they at least 
won't apply to the same row of the stack trace since once a line is 
de-obfuscated it wouldn't be do-obfuscated a second time?

Original comment by [email protected] on 22 Jun 2011 at 10:37

[GoogleCodeExporter]

I guess the method must be returning the original string if 
permutationStrongName isn't found (the only way this will work). Didn't look 
into that code. I would actually prefer the suggested patch instead.

Original comment by [email protected] on 23 Jun 2011 at 2:16

[GoogleCodeExporter]

Having to specify all the symbolMaps folders is a bit more cumbersome than
just scanning all the folder in the given symbol maps files, I agree.
 Currently gwt always puts the symbol maps in the
war/WEB-INF/deploy/<moduleName>/symbolMaps folder, it's nice to just support
that path out of the box.  But ... I guess it works either way.  The way it
was implemented is more flexible and maybe slightly faster since it avoids
getting a directory listing each time.

Original comment by [email protected] on 23 Jun 2011 at 2:25

[GoogleCodeExporter]

> Currently gwt always puts the symbol maps in the
> war/WEB-INF/deploy/<moduleName>/symbolMaps folder
This is not entirely true. "WEB-INF/deploy/" is just the default of the 
"-deploy" compiler argument and this can be changed.

So I guess, gwt-log could look there if the init-param was specified and only 
complain if it doesn't find the symbol maps. But the init-param should still be 
available if needed.

Original comment by [email protected] on 23 Jun 2011 at 7:41