Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
It seems more robustness around setting symbolMaps is desired.
Original comment by fredsa
on 25 Jun 2013 at 12:51
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
Original issue reported on code.google.com by
luiz.mi...@gmail.com
on 22 Feb 2012 at 7:10Attachments: