Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
I just finished reading the paper presented at:
depicting some of the areas/improvements he has made to what I personally consider a vital area and a great addition to gwt-core namely logging and proper mapping to java sources in production.
Looking at the donations made so far and obviously at first glance it doesn't look like this work has the significance to many that one might expect. I really feel like the amount of work, complexity of the issue at hand and the overall contribution of the work made by +Alex Epsthteyn is important enough so that we shouldn't let it go unnoticed. By unnoticed I mean how do we find a way to work with him so that his changes are ported and integrated into gwt core.
Are there any plans or conversations regarding this topic among the core GWT developers? Any way to bring, help Alex so he can incorporate/merge a lot of the changes he has made so everyone benefits from it?
I apologize before hand if there are conversations about this somewhere else and I have missed them.
Alfredo
On Fri, Jul 19, 2013 at 12:56 AM, Alex Epshteyn <alexander.epshteyn@gmail.com> wrote:
In response to some of the concerns expressed in this thread, I'd like to clarify that by using my patch, you will not be making any trade-offs versus what you previously had with GWT's old implementation: my patch will give you all "pros" and no "cons."
Here's why:There are two ways to get perfect stack traces in production: 1) via a compiler-generated source map file in a browser that provides JS stack traces with column numbers (only Chrome right now) and 2) via stack emulation for all other browsers. My project implements both solutions, along with lots of improvements to their existing implementations in GWT. So if anyone is already using any of the following: stack emulation, symbol maps, source maps, StackTraceDeobfuscator, etc., my patch will make those things better for you without requiring you to use other pieces that you don't need. For example, you could configure it to only use solution #1: which gives you perfect stack traces for Chrome and doesn't increase the size of your code. Or you could additionally enable solution #2, which will cover all the other browsers, with only 45% overhead in code size for those other browsers. Personally, I think that 45% is totally worth it (especially compared to the 100% overhead incurred in the original solution), and I'm using it in my app, but if you don't want any overhead, you can just take the freebie for Chrome and leave the rest as before.By the way, who wants to try it? Please get it touch with me (alex at typeracer.com), and I will email you my patch so you can see for yourself how awesome it is.--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
Alfredo Quiroga-Villamil
AOL/Yahoo/Gmail/MSN IM: lawwton
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home