GWT:使用StackTraceDeobfuscator远程记录和反混淆堆栈跟踪

时间:2015-01-09 22:52:19

标签: java gwt logging

我遇到了一个问题,我正在使用远程日志记录,并且我的堆栈跟踪被混淆了。我对此做了很多研究,this blog可能是我发现的最有用的参考。但是,从博客中查看提示5和6,我得到的结论是StackTraceDeobfuscator可以在不将以下内容添加到我的GWT模块的情况下使用

<set-property name="compiler.stackMode" value="emulated" />
<set-configuration-property name="compiler.emulatedStack.recordLineNumbers"
value="true" />

我宁愿不设置compiler.stackMode属性并增加我的javascript包的大小,但我开始怀疑它是否可能。以上属性实际上是对我的客户端堆栈跟踪进行反混淆处理的要求吗?还有其他选择吗?我希望避免进行可能影响应用程序性能或安全性的更改。

谢谢!

1 个答案:

答案 0 :(得分:0)

我提供反混淆堆栈跟踪的初始方法涉及不情愿地设置我在描述中提到的属性。

<set-property name="compiler.stackMode" value="emulated" />
<set-configuration-property name="compiler.emulatedStack.recordLineNumbers"
value="true" />

然而,这些新的编译指令确实增加了我的Javascript的大小,并导致性能问题。使用我们的一些客户仍在使用的Internet Explorer 8时,您可以在网站上执行一些操作,这将导致“长时间运行的脚本”弹出窗口。

我在说明中未提及的一个重要细节是此问题在GWT升级期间浮出水面。

以前,我们在GWT的com.google.gwt.logging.server.StackTraceDeobfuscator子类中使用RemoteServiceServlet。该Deobfuscator现已弃用,我们已移至com.google.gwt.core.server.StackTradeDeobfuscator。事实证明,所提到的问题与用于从新的静态工厂方法获得StackTraceDeobfuscator的符号映射目录路径相关联。修复后,我可以删除compiler.stackModecompiler.emulatedStack.recordLineNumbers属性,同时仍然从客户端接收到经过反混淆的堆栈跟踪。