How to debug GWT client side code on jboss

Question

I\'m starting with GWT and smartgwt, and I realized that when your code works on jetty will no necessarily work on Jboss.

Is there a way that I can debug exceptions or

Answer 1

I know this is an old question, but since the previous answer wasn't marked as accepted, here is the way I do it:

1. You can use SDBG, which is a nice plugin for Eclipse that allows you to debug your client side code from within Eclipse. Watch the introductory tutorial on that page to get you started. I use Glassfish, not the embedded Jetty, and I know it works with JBoss as well.
2. If you use Eclipse & Maven, I provide here a more complete list of things you can do to debug SmartGWT in both server and client side code.

Answer 2

With JBoss EAP7 and GWT 2.7 that dropped DevMode in favor of SuperDevMode, the things got a bit more complex. Related articles (Super Dev mode in GWT) provide good clues but none worked straight for my combination of servers and versions: JBoss EAP 7.0, GWT 2.7, GWT 2.7 plugin for Eclipse, Eclipse 4.5+, and Maven Builds. The key change is how to deploy the WAR with GWT code to JBoss EAP 7.

I advise you to read the introduction to GWT Super Dev Mode

1. let's assume you have an existing GWT Eclipse project that builds with Maven and that you are able to deploy and execute. The Build shall produce an exploded WAR version into your myProject/target/myWebInterface-1.0/ in addition to the packed WAR archive version like myProject/target/myWebInterface-1.0.war. You may want to check that the GWT maven plug-in notably builds myModule.devmode.js, and myModule.nocache.js in a GWT module sub-dir under myWebInterface-1.0/.

2. forget the packed .war and DO deploy the exploded version into your JBoss server via the JBoss console: Deployments > Add > Create an unmanaged deployment > Next. Fill up like below:

   Be sure to terminate name fields in ".war" although you are not deploying from a packed archive but from the directory path. This enables JBoss to understand the deployment profile to apply, that of a WAR. You may indeed check that the deployment went through OK and that your interface is running.

3. In Eclipse, open Project properties of your project, navigate in the left tree to the Google > Web Application tab and ensure the 'This project has a WAR directory' is checked. Also navigate to the Google > Web Toolkit tab and ensure 'Use GWT' is checked.

4. Right-click your project in Eclipse and Run as > . The GWT code server has been launched and will likely fail (or at minimum generate errors before telling it's ready) because of missing library dependencies. However a launch configuration has been created that will be easy to fix. So DO kill the current launch from the Eclipse Console red STOP button.

5. We need to edit the default launch configuration just created and supply all library dependencies to the CodeServer, as follows:

   • in Eclipse top menu: Run > Run Configurations... > select the Google Web Application just created
   • under the Server tab, check OFF the 'Run built-in server' (at port 8888) and click 'Apply'
   • under the 'Arguments' tab, you must see a '-noserver' option
   • fix the JRE under the JRE tab if needed to match the JDK of your Eclipse IDE
   • under the 'Classpath' tab, under 'User entries', you must add all the library dependencies from your original WAR build. Best is to created Eclipse User Libraries with all those dependencies fetched from your Maven .m2 local repository. In my case, I have added all Spring Framework libraries that support a back-end REST server deployed in the same WAR archive alongside the GWT front-end.
   • click 'Apply' then 'Run' this updated configuration
   • The Eclipse console typically displays "The code server is ready at http://127.0.0.1:9876/". Check no errors precede this trace.

6. Open that above link in a new Chrome window; you shall see

   and add bookmarks to your Chrome favorite bookmarks as indicated on that page

7. open a new Chrome browser tab on the deployed (exploded / unmanaged) web project home page

8. click the 'Dev Mode On' bookmark. A frame pops up that proposes to 'compile' your GWT module. Click on it and the frame displays 'Compiling yourModuleName'. You may also follow the GWT code Server activity in the Eclipse console, and ensure you have supplied all needed library dependencies while it re-compiles the GWT java code.

   In case you get 'Compiling myModule Failed' a Refresh of the Browser window may solve the issue whereas the proposed 'Try Again' will not work...

9. From that point, you can change GWT java sources in Eclipse and then Refresh your browser Window to see immediately the effect of the changes you make.

Debugging GWT code

10. You may further debug GWT code by setting breakpoints in the Java sources whereas that Java code is compiled and executed as Java Script in your client browser! That's magic! Proceed as follows:
    • while in Chrome, activate Developer Tools : press ctrl-shift-i or click on the settings icon > More tools > Developer tools
    • ensure that you have 'JavaScripts source maps' enabled: click the tools settings icon > Settings > ...
    • You can then navigate to GWT java sources in the left hand navigation tree (bottom of the tree), else hit ctrl-p to quickly open a source file you know (e.g. that currently edited in Eclipse), and set breakpoints in Chrome Developer Tools central panel; the debugger will execute and stop at the breakpoint when you refresh the web page, and let you inspect JavaScript variables mapped to the original java code. Do note that breakpoints are only set from Chrome Developer Tools and forget about Eclipse own breakpoints.

How it works, very briefly:

• Eclipse builds are directly consumed by JBoss thanks to the exploded/unmanaged deployment; no copy is made that would require an explicit redeployment with every change.
• GWT Code Server that is part of the GWT plugin for Eclipse detects changes in sources and re-compiles the Java Script for the client on the fly
• the client Browser gets at all times hot re-compiled Javascript from the Code Server instead of fetching them from a deployed (static) WAR archive
• the code server starts by default a jetty web server (at port 8888) to deploy the server side code but we turned that off and use the JBoss server instead with an explicit exploded/unmanaged deployment.

Answer 3

I assume you already have the launch configurations set up correctly (pointing the launch environment to JBoss instead of embedded Jetty). If you are in dev mode you should already be able to debug the javacode. If you want to debug the client side code in production use browser's dev tools.

Regarding error handling There are two ways which you can handle the GWT client side exceptions.

1. Log them in the client side
2. Send them to server and log them in the server side

I think you are after server side logging (in fact that's what we need in production mode) GWT has a well defined error handling mechanisms for both client and server side. These answers/posts will help you yo set up error handlers in your GWT app properly.

7 Tips for Exception Handling in GWT

Setup a remoteLoggingServlet in GWT