RemoteLoggerServlet should accept war relative symbolMap path

[GoogleCodeExporter]

What version of GWT are you using? 1.4.60? 2.0.4? Other?
2.4.0

What version of the gwt-log jar file or library file are you using?
3.1.8

What operating system(s) are you using? Windows? Linux? Mac?
Linux, Ubuntu 11.10

Currently, RemoteLoggerServlet accepts only paths relative to the server's 
current directory in symbolMaps parameter, witch turns impossible to deploy the 
app in some JEE containers. For example, in JBoss 7, the directory where the 
war is exploded is different for each deploy.

The attached patch changes RemoteLoggerServlet to accept another parameter, 
'isWarRelativePath'. If 'isWarRelativePath' = true, then the symbolMaps paths 
are considered to be relative to the application context path, e. g.:

<servlet>
 <servlet-name>gwt-logger-servlet-monitor</servlet-name>
 <servlet-class>om.allen_sauer.gwt.log.server.RemoteLoggerServlet</servlet-class>
 <init-param>
  <param-name>symbolMaps</param-name>
  <param-value>WEB-INF/deploy/module_name/symbolMaps/</param-value>
 </init-param>
 <init-param>
  <param-name>isWarRelativePath</param-name>
  <param-value>true</param-value>
 </init-param>
</servlet>

Original issue reported on code.google.com by luiz.mi...@gmail.com on 22 Feb 2012 at 7:10

Attachments:

• fix_remote_logger_war_relative_path.patch

[GoogleCodeExporter]

This doesn't seem to fix it for Tomcat..  How about letting us give a URI for 
the symbol path instead?  Wouldn't that work in all cases???

Original comment by andy.moo...@gmail.com on 2 Mar 2012 at 2:18

[GoogleCodeExporter]

I just tested this fix on JBoss 7, but it should work on all JEE containers, 
accordingly to the specification. I will do some tests later. What OS and 
Tomcat version did you test? Did you apply the patch on trunk?

About the URI, I don't see how it would fix the problem. Can you explain the 
idea? 

Original comment by luiz.mi...@gmail.com on 2 Mar 2012 at 2:39

[GoogleCodeExporter]

My mistake I think - it does seem to fix it in Tomcat generally.  We are 
running embedded TOMCAT and there seems to be a problem but I think it is of 
our making relating to which gwt-log jar it is picking up...  Sorry for the 
false alarm. 

Original comment by andy.moo...@gmail.com on 7 Mar 2012 at 5:45

[GoogleCodeExporter]

I am using gwt-log directly through maven repository, are these changes 
included in the maven repository build?

Original comment by fairoz...@gmail.com on 28 Mar 2012 at 1:00

[GoogleCodeExporter]

No, it seems the patch wasn't reviewed by gwt-log developer(s) yet. If you want 
to use this fix, you have to checkout the source from svn, apply the patch and 
package the lib.

Original comment by luiz.mi...@gmail.com on 28 Mar 2012 at 1:13

[GoogleCodeExporter]

See 
http://code.google.com/p/gwt-log/source/detail?r=744ae5ea4c2d99a5b69988165447f51
9f998bac5 which added support for multiple symbolMaps directories (so one 
web.xml can be used in multiple environments). Each directory will be tried in 
turn and passed into the StackTraceDeobfuscator constructure, which appears to 
take either relative or absolute paths 
(http://code.google.com/p/google-web-toolkit/source/search?q=StackTraceDeobfusca
tor&origq=StackTraceDeobfuscator&btnG=Search+Trunk).

See 
http://code.google.com/p/gwt-log/wiki/GettingStarted#Enable_the_remote_logging_o
ption_(disabled_by_default) for some examples of specifying multiple 
directories.

Original comment by fredsa on 30 Apr 2012 at 11:16

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for your answer, but the multiple symbolMaps directories and the current 
implementation of StackTraceDeobfuscator constructor doesn't solves the 
problem. Let me explai why: Since the constructor just send the string path to 
a File object, the path is only relative to the directory where the user starts 
the process, not the path where the app is deployed, wich is a problem for most 
JEE container, like JBoss for example, where the path of deployed app is 
unpredictable. 

Original comment by luiz.mi...@gmail.com on 30 Apr 2012 at 11:28

[GoogleCodeExporter]

It seems more robustness around setting symbolMaps is desired.

Original comment by fredsa on 25 Jun 2013 at 12:51

• Changed state: GitPatchesWelcome

[GoogleCodeExporter]

Please have a look at my patch here: 
https://code.google.com/r/janswaelens-symbolmapslocationconfigurationext/source/
detail?r=2d9af56fe650c36dfa8e6d54e22446f51d3970ac

It allows us to use gwt-log on at least tomcat, websphere and weblogic while 
specifying the location of the symbolMaps relative to the war file (value of 
the init parameter being: WEB-INF/deploy/appname/symbolMaps/).

Suggestions are obviously welcome.

Original comment by jan.swaelens on 25 Jun 2013 at 7:22