Uncaught JavaScript errors will normally result in obfuscated stacktraces, assuming the WebAdmin/UserPortal GWT application is running in compiled (production, non-debug) mode. There should be a way to visualize and de-obfuscate stacktraces for any uncaught client-side exceptions. GWT SDK supports (server-side) stacktrace de-obfuscation via StackTraceDeobfuscator utility. Example workflow: 1, client (e.g. WebAdmin) asks Engine to de-obfuscate stacktrace (HTTP request) 2, Engine servlet picks up the request, uses StackTraceDeobfuscator utility to process request Note that step 2, requires that appropriate symbol maps are available to Engine (to be read from local filesystem by StackTraceDeobfuscator utility). Bug 1179862 therefore needs to be solved before solving this bug.
related to the client-side logging - see also bug 1049409. (In reply to vszocs from comment #0) > ... > Bug 1179862 therefore needs to be solved before solving this bug. setting this bug to Depend On Bug 1179862.
Alternative approach: use GWT emulated stack trace feature: http://stackoverflow.com/questions/10740608/negative-performance-implications-of-using-gwt-emulated-stack-trace
(In reply to vszocs from comment #2) > Alternative approach: use GWT emulated stack trace feature: > > http://stackoverflow.com/questions/10740608/negative-performance- > implications-of-using-gwt-emulated-stack-trace Above refers to ability to compile GWT application so that it already presents un-obfuscated stack trace for any client-side exception. However, this has the downside of significantly increased JavaScript output (due to embedding original Java meta-data) which hinders the end-user experience, especially on older browsers. What we could do: * during Engine build, compile two variants of WebAdmin/UserPortal (one using "native" stack traces, one using "emulated" stack traces) * add new Engine config option, e.g. "EmulateGWTStackTrace" with default value "false" (to preserve existing behavior) * when serving WebAdmin/UserPortal HTML page, check "EmulateGWTStackTrace" and if "true", load the (heavier) variant that uses un-obfuscated stack traces As mentioned in comment #0 the other option is to do GWT stack trace de-obfuscation on server (much lower client-side performance impact, but server-side changes required).
Went with the GWT stack trace de-obfuscation method from comment #0. Utilizing part of the existing GWT remote logging framework.
(In reply to Alexander Wels from comment #4) > Went with the GWT stack trace de-obfuscation method from comment #0. > Utilizing part of the existing GWT remote logging framework. From implementation perspective this seems to be the most simple approach. It's important to note that this feature works *only* when users install the optional package containing GWT symbol maps, refer to [1] for details. [1] http://www.ovirt.org/OVirt_Engine_Debug_Obfuscated_UI#Making_sure_we_have_the_right_symbol_maps
will be extremely useful when needing to debug issues originating from the UI code -> re-targeting for 3.6.
Verified in rhevm-3.6.3.4-0.1.el6 Symbol maps packages: rhevm-userportal-debuginfo-3.6.3.4-0.1.el6 rhevm-webadmin-portal-debuginfo-3.6.3.4-0.1.el6 Symbol maps location: /usr/share/ovirt-engine/gwt-symbols/{userportal,webadmin}/ Example for debugging of GWT exception on Firefox 38 ESR @ Linux, en_US locale: Locating GWT permutation in HTTP headers: -~- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 X-GWT-Module-Base: https://engine.example.com/ovirt-engine/webadmin/ X-GWT-Permutation: C2A1F45ED54CD712A69A65581DAFB343 -~- Symbol map file to use: /usr/share/ovirt-engine/gwt-symbols/webadmin/C2A1F45ED54CD712A69A65581DAFB343.symbolMap