Unfortunately, that doesn't really do the trick for us. We're talking about bugs that get hit in the field that we can't reproduce on our test systems. If we could easily hit the bugs in our test systems then we could certianly use the Java debugger as you suggest.
On Apr 30, 3:18 pm, Sripathi Krishnan <[email protected]> wrote: > For those once-in-a-blue-moon problems, have you tried OOPHM with -noserver > mode? It lets you use java debugger on production, and it works nicely.. > > I'll explain how it works - > > 1. Sync your local codebase to the *exact* revision from which your > production build was made. Very very important step. > 2. Fire up dev mode and pass -noserver to it > 3. Hit your production server with the magic > gwt.codesvr=127.0.0.1:9997parameter. > Something like > http://myproductionserver.com/index.html?gwt.codesvr=127.0.0.1:9997 > 4. Now, instead of executing the javascript code deployed on production, > the browser will execute the *equivalent* java code from your machine. > 5. Set breakpoints and browse your application -- you will get the > culprit. > > If you believe there is a problem with the java-> javascript compilation, > then this won't help you. But most of the times, its a bug with the way I > have written code, and the bug is only reproducible in production because of > the data that's out there. The above approach lets me identify the wrong > data or the wrong code .. > > --Sri > > On 30 April 2010 18:30, Shaun <[email protected]> wrote: > > > > > We're using GWT for real world projects and most of the development > > cycle is great, especially with GWT 2.0, where we have Firebug etc to > > help out. However, now we've got deployed apps in the field we've > > found one pain point is that the errors that we tend to get have > > JavaScript line numbers for the compiled source and we can't work out > > what the corresponding Java function is in order to debug. > > > Does anyone know of a good way to work this out (e.g. a magic compiler > > flag to output a "symbol table" or similar)? For reproable problems > > we can just fire up the pretty version of the source but for once-in- > > blue-moon problems that's not possible. > > > If there isn't a feature to allow this right now, would GWT consider > > adding it to SOYC, say? > > > Thanks, > > > -Shaun > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<google-web-toolkit%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
