Re: RequestFactory module - queue, retry and non atomic batching..
H. Guess not a lot of demand then. Will hold off doing any more work on this. Cheers Sam On Wednesday, July 17, 2013 9:04:53 AM UTC+1, salk31 wrote: https://github.com/salk31/gwt-rf-queue I've been allowed to open source this and given two hours a week to work on it... I thought it was worth sharing now that it compiles and there is a working demo. I've grafted it onto the dynatablerf sample and added some controls to fake auth and network failure. So, any thoughts on if this is worth pushing on with? A real generic need? I've missed an existing solution? Cheers Sam -- 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: RequestFactory module - queue, retry and non atomic batching..
FYI, I still haven't found the time to look at it… On Thursday, July 18, 2013 9:26:35 AM UTC+2, salk31 wrote: H. Guess not a lot of demand then. Will hold off doing any more work on this. Cheers Sam On Wednesday, July 17, 2013 9:04:53 AM UTC+1, salk31 wrote: https://github.com/salk31/gwt-rf-queue I've been allowed to open source this and given two hours a week to work on it... I thought it was worth sharing now that it compiles and there is a working demo. I've grafted it onto the dynatablerf sample and added some controls to fake auth and network failure. So, any thoughts on if this is worth pushing on with? A real generic need? I've missed an existing solution? Cheers Sam -- 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: RequestFactory module - queue, retry and non atomic batching..
Ho k... I'll be very interested to hear your thoughts... If you think it is fixable maybe GAE demo with some UI may be next step for me? On Thursday, July 18, 2013 9:49:47 AM UTC+1, Thomas Broyer wrote: FYI, I still haven't found the time to look at it… On Thursday, July 18, 2013 9:26:35 AM UTC+2, salk31 wrote: H. Guess not a lot of demand then. Will hold off doing any more work on this. Cheers Sam On Wednesday, July 17, 2013 9:04:53 AM UTC+1, salk31 wrote: https://github.com/salk31/gwt-rf-queue I've been allowed to open source this and given two hours a week to work on it... I thought it was worth sharing now that it compiles and there is a working demo. I've grafted it onto the dynatablerf sample and added some controls to fake auth and network failure. So, any thoughts on if this is worth pushing on with? A real generic need? I've missed an existing solution? Cheers Sam -- 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.
DataGrid and using Event.setCapture to implement column resizing.
Hi, I'm currently implementing column resizing on DataGrid but I stumbled upon 2 problems. Maybe somebody from the GWT team can help me out to solve this ? It looks to me that those are bugs/features of the current DatatGrid/CellTable(s) ... but it would be great if I can get a complete working solution instead. Problem 1: Event.setCapture does not seem to work when used in a Header. My solution is to have a custom header that consumes mousedown,mouseup and mousemove events. I check if a mousedown is happening on the last pixels of the column I use setCapture on the Element. But, the capture does not work, events are still dispatched as if I did not call the setCapture. I get the mousemove events in the other header cells instead of only on the capturing column header. Is there a solution that allows me to capture all events when resizing the column ? The user has to be careful right now not to go outside the table header. Problem 2: setColumnWidth does not force an onResize on the DataGrid. To force a column resize I invoke the setColumnWidth method. My DataGrid table is wider than the allowed space, and so it needs an horizontal scrollbar. However the scrollbar does not adjust automatically when I call the setColumnWidth method. It does however update when I resize the window. I did a workaround by forcing onResize after calling the setColumnWidth, but shouln't the DataGrid do this automatically ? David -- 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: RequestFactory module - queue, retry and non atomic batching..
I'm also quite interested but haven't had time to look. On 18 July 2013 10:00, salk31 sal...@gmail.com wrote: Ho k... I'll be very interested to hear your thoughts... If you think it is fixable maybe GAE demo with some UI may be next step for me? On Thursday, July 18, 2013 9:49:47 AM UTC+1, Thomas Broyer wrote: FYI, I still haven't found the time to look at it… On Thursday, July 18, 2013 9:26:35 AM UTC+2, salk31 wrote: H. Guess not a lot of demand then. Will hold off doing any more work on this. Cheers Sam On Wednesday, July 17, 2013 9:04:53 AM UTC+1, salk31 wrote: https://github.com/salk31/gwt-**rf-queuehttps://github.com/salk31/gwt-rf-queue I've been allowed to open source this and given two hours a week to work on it... I thought it was worth sharing now that it compiles and there is a working demo. I've grafted it onto the dynatablerf sample and added some controls to fake auth and network failure. So, any thoughts on if this is worth pushing on with? A real generic need? I've missed an existing solution? Cheers Sam -- 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. -- 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: No source code is available for type com.google.gwt.user.server.rpc.RemoteServiceServlet;
Thanks! [ERROR] Line 6: No source code is available for type com.google.gwt.user.server.rpc.RemoteServiceServlet; did you forget to inherit a required module? This error disappeared after I had removed source path=server/ from my Project.gwt.xml file On Tuesday, March 23, 2010 9:44:33 PM UTC+4, Paul Robinson wrote: You have a bug in your module's .gwt.xml file here: source path=server/ This line should be removed. It's telling GWT to compile the code in your server directory to javascript. Paul -- 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: CellPreviewEvent ie - event not firing...?
Well, the patch for issue GWT 7139 solved the problem. This is the issue http://code.google.com/p/google-web-toolkit/issues/detail?id=7139can=4colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars This is the link to the patch: https://github.com/nmorel/gwt-issue7139/wiki I've edited the patche's *.gwt.xml to use this solution for ie9 as well and it worked. In conclusion, this is what I understand: DataGrid on GWT 2.5.0, when using IE (9 or 10), does not catch click events (and all other kinds of events) unless you click on a row which is already selected. This problem can be solved by this patch https://github.com/nmorel/gwt-issue7139/wiki -- 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: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet. That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development). What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. On Thursday, July 18, 2013 1:40:31 AM UTC+2, Jens wrote: Do you plan to maintain that code if it is integrated into GWT or will it be a one time contribution and other people have to wrap their head around it again if your solution needs to be adjusted? I ask this because GWT will drop support for IE6/7 relatively soon and probably by the end of 2014 drop support for IE8. Also Opera has switched to Blink/V8 which makes the opera permutation obsolete in the near future. So by the end of 2014 (GWT 3.x) Firefox, Safari, Chrome and Opera are likely to support SourceMaps and in case of IE9+ stack trace emulation is probably not needed. So by the end of next year a bunch of your code can probably be deleted and other code refactored/optimized to fit this situation. Have you thought about that? -- J. -- 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: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote: Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet. That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development). What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though. -- 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: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
Hi Thomas, It would be great if you (or anybody who understands how to set it up) could add a small article on gwtproject.org about setting up the different methods of getting stack traces in production on exceptions? Thanks! Ryan On Thu, Jul 18, 2013 at 3:30 PM, Thomas Broyer t.bro...@gmail.com wrote: On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote: Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet. That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development). What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/1qDVlPGryKo/unsubscribe . To unsubscribe from this group and all its topics, 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. -- 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: CellPreviewEvent ie - event not firing...?
Oh dear, that's an assumed stale... I have the problem on IE9/IE10. It basically blocks me from doing anything interesting in custom cells in IE9/10 I will try out the proposed solution and if it works we will need to see if this can be fixed somehow in the next GWT build. David On Thu, Jul 18, 2013 at 3:08 PM, Aya scootergi...@gmail.com wrote: Well, the patch for issue GWT 7139 solved the problem. This is the issue http://code.google.com/p/google-web-toolkit/issues/detail?id=7139can=4colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars This is the link to the patch: https://github.com/nmorel/gwt-issue7139/wiki I've edited the patche's *.gwt.xml to use this solution for ie9 as well and it worked. In conclusion, this is what I understand: DataGrid on GWT 2.5.0, when using IE (9 or 10), does not catch click events (and all other kinds of events) unless you click on a row which is already selected. This problem can be solved by this patch https://github.com/nmorel/gwt-issue7139/wiki -- 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. -- 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: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
That article was the third result in a Google search for gwt web mode exceptions: http://www.summa-tech.com/blog/2012/06/11/7-tips-for-exception-handling-in-gwt/ I agree that http://www.gwtproject.org/doc/latest/DevGuideLogging.html#Remote_Logging needs to be expanded. On Thursday, July 18, 2013 3:38:15 PM UTC+2, RyanZA wrote: Hi Thomas, It would be great if you (or anybody who understands how to set it up) could add a small article on gwtproject.org about setting up the different methods of getting stack traces in production on exceptions? Thanks! Ryan On Thu, Jul 18, 2013 at 3:30 PM, Thomas Broyer t.br...@gmail.comjavascript: wrote: On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote: Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet. That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development). What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/1qDVlPGryKo/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com javascript:. To post to this group, send email to google-we...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out. -- 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.
Changing maxBundleSize property
Hi. In order to change maximum size of a bundle i have to change gwt.imageResource.maxBundleSize property. The thing is, when I use set-property name=gwt.imageResource.maxBundleSize value=1000 / in gwt.xml, server doesn't even go up. Also, where I can find all available properties? Any advices / ideas? -- 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: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. We also do not use emulated stack traces because of performance and code size overhead. So we simply deploy the symbol maps generated by GWT compiler and use StackTraceDeobfuscator on the server. We also extended StackTraceDeobfuscator a bit because we received exceptions where the stack trace is actually inside the exception message instead of the exception stack trace (the exception stack trace was empty). So we try to deobfuscate the exception message as well in this case. Given the above the quality of stack traces now depends on the browser version our clients use. We do not support IE6/7 and IE 8 support will be dropped next year (regardless of what GWT does). So we mainly deal with newer browsers and we pretty much always get deobfuscated stack traces that provide some useful information. Its not perfect but it works. We never get the concrete line number where the exception occurs but we often enough have the method name. Of course sometimes we have no stack information at all (IE8). In addition you can enhance the stack trace by providing additional client information. For example you could send the current URL to the server which tells your the current place state if you use GWT Places. You could also implement a custom Logging Handler that logs into a ring buffer and once a client exception occurs you send the last x client log entries along with the stack trace. Or if you do not want to enable logging itself in production you could still use the ring buffer approach and store user actions in it and then send these to the server (similar to client side logging). Or you trace user click coordinates and their underlying elements (event preview handler) So before enabling full stack trace emulation in GWT you can do quite a few things to get information about what has happened inside the app once the exception had occurred. Btw. we stopped using SourceMaps for Chrome because for whatever reasons StackTraceDeobfuscator has imports from gwt-dev.jar that are needed when SourceMaps are enabled. -- J. -- 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: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
Very cool. Bob Vawter and I (and I think a couple more people) worked on this a long time ago, and there's definitely a lot of room for improvement. Nice to see someone tackle this! 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.TyperacerUncaughtExceptionHandler$1.execute(TyperacerUncaughtExceptionHandler.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/9C4DC2D905BEA407601C92C56B43E3B8.cache.html stack: @ http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2422 Rub@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2423 dSb@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:3190 tA@http://localhost:8088/9C4DC2D905BEA407601C92C56B43E3B8.cache.html:2810 Xmb@http://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/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 written a detailed white paper ( http://goo.gl/YGsrQ ) that describes how my solution works and why it is necessary. I welcome your feedback! Thanks! 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: RequestFactory module - queue, retry and non atomic batching..
Doh. Looked to see how long it would take to put it up on GAE and only took ten minutes to actually do it. http://gwt-rf-queue.appspot.com/ So good old DynaTableRf but with gwt-rf-queue but with the Transport replaced and a bit of extra UI. -- 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: DataGrid and using Event.setCapture to implement column resizing.
Not an answer to your problems, but other people in the past have followed the same road. Have a look at http://code.google.com/p/google-web-toolkit/issues/detail?id=6401 -- 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: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
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+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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote: Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet. That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development). What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though. -- 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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
That article was the third result in a Google search for gwt web mode exceptions: http://www.summa-tech.com/blog/2012/06/11/7-tips-for-exception-handling-in-gwt/ I agree that http://www.gwtproject.org/doc/latest/DevGuideLogging.html#Remote_Logging needs to be expanded. On Thursday, July 18, 2013 3:38:15 PM UTC+2, RyanZA wrote: Hi Thomas, It would be great if you (or anybody who understands how to set it up) could add a small article on gwtproject.org about setting up the different methods of getting stack traces in production on exceptions? Thanks! Ryan On Thu, Jul 18, 2013 at 3:30 PM, Thomas Broyer t.br...@gmail.comjavascript: wrote: On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote: Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet. That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development). What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/1qDVlPGryKo/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com javascript:. To post to this group, send email to google-we...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out. -- 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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. We also do not use emulated stack traces because of performance and code size overhead. So we simply deploy the symbol maps generated by GWT compiler and use StackTraceDeobfuscator on the server. We also extended StackTraceDeobfuscator a bit because we received exceptions where the stack trace is actually inside the exception message instead of the exception stack trace (the exception stack trace was empty). So we try to deobfuscate the exception message as well in this case. Given the above the quality of stack traces now depends on the browser version our clients use. We do not support IE6/7 and IE 8 support will be dropped next year (regardless of what GWT does). So we mainly deal with newer browsers and we pretty much always get deobfuscated stack traces that provide some useful information. Its not perfect but it works. We never get the concrete line number where the exception occurs but we often enough have the method name. Of course sometimes we have no stack information at all (IE8). In addition you can enhance the stack trace by providing additional client information. For example you could send the current URL to the server which tells your the current place state if you use GWT Places. You could also implement a custom Logging Handler that logs into a ring buffer and once a client exception occurs you send the last x client log entries along with the stack trace. Or if you do not want to enable logging itself in production you could still use the ring buffer approach and store user actions in it and then send these to the server (similar to client side logging). Or you trace user click coordinates and their underlying elements (event preview handler) So before enabling full stack trace emulation in GWT you can do quite a few things to get information about what has happened inside the app once the exception had occurred. Btw. we stopped using SourceMaps for Chrome because for whatever reasons StackTraceDeobfuscator has imports from gwt-dev.jar that are needed when SourceMaps are enabled. -- J. -- 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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
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. -- 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.
