subject:"\[gwt\-contrib\] Re\: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production"

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

2013-08-21 Thread Alex Epshteyn

Hi Colin, please find my answers inline:

On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth niloc...@gmail.com wrote:

 I got a tweet from you asking for a donation (or rather a 'partner', which
 apparently means 'money'), but couldn't frame a useful response in 140
 chars, so since this thread is coming back, I thought to do so here
 instead.


Yes, I wanted to see if Sencha would be interested in funding this project.
 I agree, 140 chars is not enough :)  Just couldn't find your contact info
other than Twitter.

What license are you offering these code samples under - if it isn't
 something open and available, what is the benefit to an advance copy of the
 jar if I, an author of a library and several open source tools and
 applications, cannot provide it to my customers or other downstream users?


That's a good point which I hadn't considered.  I'd be willing to
immediately release the code under the same license as GWT if the project
gets funded.

(For anyone who's just joining this thread now, here's the link to my
project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291)


 We've found that https://gist.github.com/niloc132/3906501 goes a heck of
 a long ways toward offering optional debug info - if not enabled, the user
 gets the normal-size application with zero size or performance hit, and by
 redirecting to a slightly different url, the full trace info can be pulled
 out (with the quirks you mention of course*), which typically goes a long
 ways toward identifying the real issue.


Yes, and you'd still be able to use that same config with my patch, except
the debug permutation will be much smaller, cleaner, and more accurate.  In
fact, the overhead is so insignificant now, that I have that debug
configuration enabled for all users on my site (typeracer.com).


 * How often have you needed to know which line of Impl.java or
 DOMImpl.java a stack trace intersects? To make your case more effectively,
 you might consider using code where it is meaningful to see those lines,
 something other than the equivelent of
 java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
 JSNI, or an annoying IE6-9 focus() or setAttribute issue?


Certainly.  At the time of writing I only had a few artificial examples
available.  But now that I've been gathering real data from my users in
production for a month, I will add an appendix with much better real-world
examples.  I'll update this thread when I finish doing that (most likely
tomorrow).


 You touch briefly on the risk of '[exposing] your application’s
 implementation details', but unless I am mistaken, the extra metadata
 included in the file:line ints should still be enough to take apart an app
 and map it to discrete files and reconstruct methods, even un-inlining (as
 you mention) to pull out clearer details. My understanding was that the
 premise of the sourceMap was to work entirely from the stack to allow the
 actual source to be obfuscated, and avoid any other metadata from being
 left in the compiled output. Combine this with the fact that many of those
 classes are publicly available (GWT itself, etc), and it seems that you
 could reverse out a significant portion of the app - the secret sauce.
 Can you comment on using this for public applications and any reverse
 engineering attempts you've made?


Let me first just clarify how my implementation obfuscates file names (I
think you understood it correctly, but I just want to be sure).  So in my
implementation of stack emulation, the filenames are obfuscated, so you
have strings like '23:234'. The decoding table for this cipher is not
published (it's written as a new file in the same directory as the
symbolMap).  So the only thing that you can reconstruct is that the
obfuscated JavaScript expression X is on line '234' of file '23'.  I
understand that you can use this info to separate the JS output into
discrete files, but I'm just not overly concerned with that, because I
don't think it's that much more helpful to have many obfuscated files with
prettier whitespacing instead of just one lump file.  If necessary, I
suppose you could modify the compiler to add some additional obfuscating
salt to the output.

Thanks for your questions!
Alex

-- 
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+unsubscr...@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.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

2013-08-21 Thread Alex Epshteyn

Hi Colin, please find my answers inline:

On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth niloc...@gmail.com wrote:

 I got a tweet from you asking for a donation (or rather a 'partner', which
 apparently means 'money'), but couldn't frame a useful response in 140
 chars, so since this thread is coming back, I thought to do so here
 instead.


Yes, I wanted to see if Sencha would be interested in funding this project.
 I agree, 140 chars is not enough :)  Just couldn't find your contact info
other than Twitter.

What license are you offering these code samples under - if it isn't
 something open and available, what is the benefit to an advance copy of the
 jar if I, an author of a library and several open source tools and
 applications, cannot provide it to my customers or other downstream users?


That's a good point which I hadn't considered.  I'd be willing to
immediately release the code under the same license as GWT if the project
gets funded.

(For anyone who's just joining this thread now, here's the link to my
project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291)


 We've found that https://gist.github.com/niloc132/3906501 goes a heck of
 a long ways toward offering optional debug info - if not enabled, the user
 gets the normal-size application with zero size or performance hit, and by
 redirecting to a slightly different url, the full trace info can be pulled
 out (with the quirks you mention of course*), which typically goes a long
 ways toward identifying the real issue.


Yes, and you'd still be able to use that same config with my patch, except
the debug permutation will be much smaller, cleaner, and more accurate.  In
fact, the overhead is so insignificant now, that I have that debug
configuration enabled for all users on my site (typeracer.com).


 * How often have you needed to know which line of Impl.java or
 DOMImpl.java a stack trace intersects? To make your case more effectively,
 you might consider using code where it is meaningful to see those lines,
 something other than the equivelent of
 java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life
 JSNI, or an annoying IE6-9 focus() or setAttribute issue?


Certainly.  At the time of writing I only had a few artificial examples
available.  But now that I've been gathering real data from my users in
production for a month, I will add an appendix with much better real-world
examples.  I'll update this thread when I finish doing that (most likely
tomorrow).


 You touch briefly on the risk of '[exposing] your application’s
 implementation details', but unless I am mistaken, the extra metadata
 included in the file:line ints should still be enough to take apart an app
 and map it to discrete files and reconstruct methods, even un-inlining (as
 you mention) to pull out clearer details. My understanding was that the
 premise of the sourceMap was to work entirely from the stack to allow the
 actual source to be obfuscated, and avoid any other metadata from being
 left in the compiled output. Combine this with the fact that many of those
 classes are publicly available (GWT itself, etc), and it seems that you
 could reverse out a significant portion of the app - the secret sauce.
 Can you comment on using this for public applications and any reverse
 engineering attempts you've made?


Let me first just clarify how my implementation obfuscates file names (I
think you understood it correctly, but I just want to be sure).  So in my
implementation of stack emulation, the filenames are obfuscated, so you
have strings like '23:234'. The decoding table for this cipher is not
published (it's written as a new file in the same directory as the
symbolMap).  So the only thing that you can reconstruct is that the
obfuscated JavaScript expression X is on line '234' of file '23'.  I
understand that you can use this info to separate the JS output into
discrete files, but I'm just not overly concerned with that, because I
don't think it's that much more helpful to have many obfuscated files with
prettier whitespacing instead of just one lump file.  If necessary, I
suppose you could modify the compiler to add some additional obfuscating
salt to the output.

Thanks for your questions!
Alex

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production

2013-08-20 Thread Brian Slesinsky

Thanks for looking into how to improve Java stack traces. I agree that we
could do a better job. However, there are some problems with your approach:

First of all, we can't guarantee that we will accept this change. That
doesn't seem very fair to whoever might be donating money.

I would like to make sure we come up with a solution taking the best
features of everyone's ideas, while remaining as simple as possible. See
the discussion about GWT.create() improvements for an example. So the final
result will likely be modified and include ideas from multiple
contributors, though course the person who volunteers to do most of the
work often has the largest influence. And simple patches aren't a solo
effort because someone has to review them and try them out.

With a project as complex and widely used as GWT, the drawbacks to a change
may be unexpected. It's unfortunate, but we often find that after
committing a change to Google's codebase, we discover problems that nobody
thought of in review and we not caught by GWT's own tests. It's much easier
to test a change if it's broken up into smaller patches.

So if possible it's best to split up a larger feature into smaller patches
and consider each of them on their merits. For example, if some things are
just bug fixes, we should review and commit them separately. This is often
a good way to get started in the community - before trying something large,
fix simpler bugs. This gives us a chance to get to know your work through
smaller and less risky changes, and you'll likely learn things along the
way. Resist the urge to add more features since that makes a change riskier
and harder to get agreement on.

- Brian

On Mon, Aug 19, 2013 at 1:06 PM, Alex Epshteyn alexander.epsht...@gmail.com
wrote:

Hello folks,

I just wanted to remind everyone that the last day to fund this project is
this Friday, August 23.

I've been using this framework in production in my app now for 2 months,
and it works great. Have logged 70,000 perfect stack traces so far!
Already fixed 3 major bugs in my GWT-based UI code that I would NEVER
found otherwise.

Let's get this capability into GWT by the end of the year. Please donate!

Thanks,
Alex

On Wednesday, July 17, 2013 4:56:40 PM UTC-4, Alex Epshteyn wrote:

Dear fellow GWT users,

I would like to announce that I have finally solved what I always thought
to be GWT's greatest weakness: its lack of debugging information for
client-side exceptions in production.

With my patch, your deployed app will be able to report stack traces like
this:

com.google.gwt.core.client.**JavaScriptException: (TypeError) : a is null
com.google.gwt.dom.client.**DOMImplMozilla.$**getBodyOffsetLeft(**
DOMImplMozilla.java:145)
com.google.gwt.user.client.ui.**PopupPanel.$setPopupPosition(**
Document.java:1287)
com.google.gwt.user.client.ui.**PopupPanel.setPopupPosition(**
PopupPanel.java:884)
com.google.gwt.user.client.ui.**PopupPanel.PopupPanel(**
PopupPanel.java:453)
com.typeracer.commons.client.**widgets.EnhancedPopup.**
EnhancedPopup(EnhancedPopup.**java:32)
com.typeracer.commons.client.**widgets.PopupWithIcon.**PopupWithIcon(**
PopupWithFocusableTextBox.**java:28)
com.typeracer.main.client.**controller.**TyperacerUncaughtExceptionHand**
ler$1.execute(**TyperacerUncaughtExceptionHand**ler.java:55)
com.google.gwt.core.client.**impl.SchedulerImpl.**runScheduledTasks(**
SchedulerImpl.java:50)
etc... :-)

instead of the current state of affairs that looks like this:

lineNumber: 3190 columnNumber: 15354: a is null; (TypeError) fileName:
http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**B8.cache.htmlhttp://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html

stack: @http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
B8.cache.html:2422http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422

Rub@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
B8.cache.html:2423http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423

dSb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
B8.cache.html:3190http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190

tA@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
B8.cache.html:2810http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810

Xmb@http://localhost:8088/**9C4DC2D905BEA407601C92C56B43E3**
B8.cache.html:2289http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2289

etc... :-(

I am asking the community to support me in finishing this effort and
integrating my patch into GWT. Please take a look and what I've done, and
consider making a donation:

http://igg.me/at/gwt-stack-**traces/x/3494291http://igg.me/at/gwt-stack-traces/x/3494291

I am an indie developer and I just need some funding to continue this
work. I'm looking for both grassroots and corporate sponsorship for my
quest of improving GWT's error reporting and debugging support.

I've