You have a few options. If you compile your project with -extra this
will create a symbol map with obfuscated function names mapped to
class names and line numbers. Another option it to turn on stack trace
emulation (http://code.google.com/p/google-web-toolkit/wiki/
WebModeExceptions). This will allow you to get a stack trace in terms
of java functions. On all browsers except Firefox, this will increase
the code size considerably. Another option is to compile your code
with an output style of pretty. This is the best option if you need to
debug the javascript in something like firebug.


On May 4, 3:56 am, Shaun <[email protected]> wrote:
> 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
> > > JavaScriptlinenumbers 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%2Bunsubs
> > >  [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 
> 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.

Reply via email to