log

gistfile1.txt

<jhrcek> manstis: I'm not sure if they'll help me with this particular issue. In 7.0 we've been seeing this kind of client-side-only error quite often and it's often hard to debug https://issues.jboss.org/secure/attachment/12419498/Error.png
<jhrcek> manstis: this kind of errors is very hard to debug if there's no associated backend message.
<manstis> jhrcek, do yuo see it *everywhere* or just the security screens?
<manstis> jhrcek, that type of error is easily debugged in dev mode.. but in the compiled webapp the Javascript is obfusicated
<manstis> obfusicacted/optimised/munged
<jhrcek> manstis: I mean in general - modal with error like "Type error <some obfuscated variable>: null"
<manstis> jhrcek, well.. afaik there's no reason it should be a generic issue; but I suspect a number of similar problems
<manstis> however I know tsurdilo had a recent problem on designer where some old (reliable) code stopped working recently
<manstis> which could suggest, if you're seeing similar, that something in possible errai has changed and is causing failures
<jhrcek> manstis: I can give you example screenshot with identical issue that something was null and usually the underlying error is "something not initialized properly" 
* krisv has quit (Read error: Connection reset by peer)
<manstis> but atm unless we can pinpoint a specific and debug to see why it's failing.. we can only guess
* krisv (~krisv@ptr-uc611rt375p23mihoc.18120a2.ip6.access.telenet.be) has joined
<manstis> jhrcek, specific steps to reproduce are much more welcome! ;-)
* lleverich has quit (Ping timeout: 240 seconds)
* lleverich (~lleveric@47-41-17-20.dhcp.mtpk.ca.charter.com) has joined
<jhrcek> manstis: I had more "generic" solution in mind. This kind of error is usually shown by this: https://github.com/AppFormer/uberfire/blob/master/uberfire-extensions/uberfire-widgets/uberfire-widgets-commons/src/main/java/org/uberfire/ext/widgets/common/client/callbacks/DefaultErrorCallback.java#L65
<manstis> jhrcek, only if (1) the error is as a result of a server-side call, (2) people use that as their "error callback"
<jhrcek> manstis: when only the exception message is shown ("something" is null) which is usually not helpful. And when steps to reproduce are dificult (like setup kie-wb + kie-server + backend DB) engineers usually postpone the fixes.
<manstis> jhrcek, we don't know if the error is complete unrelated to server-side calls atm
* karreiro (~karreiro@redhat/jboss/karreiro) has joined
<jhrcek> manstis: I know that it wouldn't solve all our issues, but this particular "Unable to complete your request. The following exception occurred: " happens so often, that I think including stacktrace somewhere (some hidden element in html client-side?) would make troubleshooting much faster.
<manstis> jhrcek, the problem is in the compiled webapp the stack trace is going to be obfusicated too; so pretty much meaningless (same as the error you pasted)
* salaboy (~salabvoy@host109-145-74-212.range109-145.btcentralplus.com) has joined
* ederign (~ederign@redhat/jboss/ederign) has joined
<jhrcek> manstis: is that so? I thought that's the point of those "portable exceptions" that the stacktrace is preserved.
<manstis> jhrcek, portable exception is a server side exception that is "portable" to the browser (i.e. can be marshalled by errai)
<manstis> jhrcek, I guess we can dump it's trace (should come from the server, so should be more readable)
<manstis> however server side errors are also logged in the app server logs
<manstis> so IF what you see was coming from the server I'd expect a server log entry too
<manstis> so I suspect purely 100% client side problems
<manstis> tbh
<jhrcek> manstis: so this means for client-side-only errors we're back to case-by-case :'(
<manstis> jhrcek, well.. there might be an optin to compile the webapps w/o obfusicated source.. so the error + stack trace (in chrome devtools) is more meaningful
<manstis> but the regular webapp is compiled obfusicated
<jhrcek> manstis: so we would sse meaningful stacktraces IF we comile un-obfuscated and IF we change the DefaultErrorCallback to show it somewhere, right?
<manstis> jhrcek, well.. if running unobfusicated you can probably put a break point in the DefaultErrorCallback
<manstis> but I get where you're heading ;-)
<jhrcek> manstis: the point is to be able for us to provide quicker and more specific hints where the problem is coming (as opposed to: I see uninformative error after doing this super complex setup). With minimal effort for QE. Some severe errors with trivial fixes remain unfixed for months because of this.
<jhrcek> *coming from
<manstis> jhrcek, what makes you think their trivial ;-)
<manstis> jhrcek, does QE just use the normal wars?
<manstis> or do you compile them?
* jsoltes (jsoltes@nat/redhat/x-mkrmrujunozttojl) has joined
<jhrcek> manstis: like one-line fix
 jhrcek jeremyl jiana jlocker jomarko jrenaat jschwan jsoltes 
<manstis> jhrcek, but you don't know they're one line fixes until we know the cause
<manstis> anyway.. see https://gwt-maven-plugin.github.io/gwt-maven-plugin/compile-mojo.html
<jhrcek> manstis: Compiling locally only when we want to check unmerged PRs locally - otherwise working with already-comiled kie-wb snapshots.
<manstis> the "style" attrbiuted. default is OBF but the webapps could be recompiled with DETAILED
<jhrcek> manstis: ok, this should at least make it possible to debug this kind of issue :) I'll look into this more. Thanks
<manstis> jhrcek, I am happy to help in any way we can; if you want a GWT.log(ex.message()) or something in DefaultErrorCallback jsut ask
<jhrcek> manstis: I already asked about GWT.log today. Copy-paste: I'm trying to debug some client-side code using GWT.log(...) but id doesn't show anything in the browser JS console. What extra steps do I need to make those messages appear in the console?