SuperDevMode and -noserver (Tomcat) debugging

1,019 views
Skip to first unread message

Thad Humphries

unread,
Feb 13, 2014, 11:08:50 PM2/13/14
to google-we...@googlegroups.com
I thought I had this working, and I do, but only in one project. Now I'm trying to recreate the magic, and it's not working.

I've an older project that I started running SuperDevMode from a console and DevMode from Eclipse. Since I wanted some features of Tomcat, I switched to running the app as a Remote Java Application. Debugging works. Moreover, when I make a change in a server-only class--like a servlet--the change is there on the very next run.

I want to recreate what I've done and document it for the next guy. Accordingly I

1) Generate a new project, Foo, using the gwt-maven-plugin archetype.

2) Add pluginManagement for org.eclipse.m2e to my pom.xml so Eclipse won't squawk about i18n and import the project (see http://stackoverflow.com/questions/16068127/maven-gwt-2-5-1-setup-issue)

3) Add 

  <add-linker name="xsiframe"/>
  <set-configuration-property name="devModeRedirectEnabled" value="true"/>

to the module file.

4) Run `mvn clean generate-sources gwt:run` from a console.

5) Launch the app in the browser then quit DevMode.

6) Copy target/Foo-1.0-SNAPSHOT to $CATALINA_HOME/webapps/Foo

7) Run `mvn clean generate-sources gwt:run-codeserver` from a console.

8) In Eclipse, create a Debug Remote Java Application on Foo and run it.

9) Open http://localhost:8080/Foo in my browser (Chrome).

10) Turn Dev Mode On. Compile. Project runs.

If I put a breakpoint in my servlet (GreetingServiceImpl), it breaks in the Eclipse debugger.

11) Disconnect from Tomcat (in Eclipse). Modify GreetingServiceImpl.java. Restart the remote debug in Eclipse.

12) In the browser, turn Dev Mode Off, turn Dev Mode On, and Compile

When I call the RPC function, the change made in Step #11 does NOT take effect, though I can see those changes while stepping through GreetingServiceImpl in the Eclipse debugger.


What could I be missing? As I said, in my older project (which has gone through some evolution from 2.5.1 to 2.6.0, from DevMode to SuperDevMode and -noserver, from Java 1.5 to 1.6 to 1.7, etc.) server-side changes show on the next run. What might be missing from a archetype generated project and/or from my Eclipse configuration that would cause server-side change to NOT take effect in Foo when they do elsewhere?

Thad Humphries

unread,
Feb 13, 2014, 11:12:09 PM2/13/14
to google-we...@googlegroups.com
Sorry, I meant to add that when I run-codeserver, I do see this anomaly:

[INFO]    Compiling 1 permutation
[INFO]       Compiling permutation 0...
[INFO]       Source Maps Enabled
[INFO]    Compile of permutations succeeded
[INFO] Linking into /var/folders/t3/2t6b810n69q0vl26t99wsxmc0000gp/T/gwt-codeserver-4178506489384599107.tmp/org.codehaus.mojo.Foo/compile-1/war/Foo; Writing extras to /var/folders/t3/2t6b810n69q0vl26t99wsxmc0000gp/T/gwt-codeserver-4178506489384599107.tmp/org.codehaus.mojo.Foo/compile-1/extras/Foo
[INFO]    Link succeeded
[INFO]    Compilation succeeded -- 7.514s
[INFO] Compile completed in 7961 ms
[ERROR] 2014-02-13 22:33:48.198:INFO:oejs.Server:jetty-8.y.z-SNAPSHOT
[ERROR] 2014-02-13 22:33:48.228:INFO:oejs.AbstractConnector:Started SelectChann...@127.0.0.1:9876
[INFO] 
[INFO] The code server is ready.
[INFO] Next, visit: http://localhost:9876/

What is this ERROR trying to tell me? Could it be the culprit?

Thomas Broyer

unread,
Feb 15, 2014, 7:22:10 AM2/15/14
to google-we...@googlegroups.com


On Friday, February 14, 2014 5:08:50 AM UTC+1, Thad Humphries wrote:
I thought I had this working, and I do, but only in one project. Now I'm trying to recreate the magic, and it's not working.

I've an older project that I started running SuperDevMode from a console and DevMode from Eclipse. Since I wanted some features of Tomcat, I switched to running the app as a Remote Java Application. Debugging works. Moreover, when I make a change in a server-only class--like a servlet--the change is there on the very next run.

I want to recreate what I've done and document it for the next guy. Accordingly I

1) Generate a new project, Foo, using the gwt-maven-plugin archetype.

2) Add pluginManagement for org.eclipse.m2e to my pom.xml so Eclipse won't squawk about i18n and import the project (see http://stackoverflow.com/questions/16068127/maven-gwt-2-5-1-setup-issue)

You'd better just remove the <goal>i18n</goal> line from the generated project. That's one of the things that are plain wrong with the archetype (and the gwt-maven-plugin), IMO.
 
3) Add 

  <add-linker name="xsiframe"/>
  <set-configuration-property name="devModeRedirectEnabled" value="true"/>

Note that in 2.6.0 you no longer need that second line, it's enabled by default.
 
to the module file.

4) Run `mvn clean generate-sources gwt:run` from a console.

No need to include "generate-sources" here, gwt:run should fork an "mvn process-classes" when run.
 
5) Launch the app in the browser then quit DevMode.

6) Copy target/Foo-1.0-SNAPSHOT to $CATALINA_HOME/webapps/Foo

Wouldn't it be easier to run "mvn package" or "mvn package -Dgwt.compiler.skip" ? (you need the GWT compile on the very first time though)
But actually, much better would be to just point Tomcat at your target/Foo-1.0-SNAPSHOT, or start Tomcat using the tomcat7-maven-plugin (unless you have some special Tomcat config that you cannot replicate with the tomcat7-maven-plugin).
 
7) Run `mvn clean generate-sources gwt:run-codeserver` from a console.

There you should use "process-classes" instead of "generate-sources". Note that gwt:run-codeserver seems to be fixed in 'master', maybe I'll release 2.6.0-1 this week-end, but in the mean time you can build the plugin yourself to try it out.
 
8) In Eclipse, create a Debug Remote Java Application on Foo and run it.

9) Open http://localhost:8080/Foo in my browser (Chrome).

10) Turn Dev Mode On. Compile. Project runs.

If I put a breakpoint in my servlet (GreetingServiceImpl), it breaks in the Eclipse debugger.

11) Disconnect from Tomcat (in Eclipse). Modify GreetingServiceImpl.java. Restart the remote debug in Eclipse.

You shouldn't need to restart remote debugging.
 
12) In the browser, turn Dev Mode Off, turn Dev Mode On, and Compile

Note that you don't need to "Dev Mode Off", you can just click again on "Dev Mode On" at will.
 
When I call the RPC function, the change made in Step #11 does NOT take effect, though I can see those changes while stepping through GreetingServiceImpl in the Eclipse debugger.

Are you sure you're *seeing* these changes? Sure Eclipse shows you your local source file, but are you sure it's in sync with the code that actually runs? (I doubt it)
 
What could I be missing?

You didn't re-deploy your modified class to your Tomcat instance, so it's still running the one you put there at step #6.
 
As I said, in my older project (which has gone through some evolution from 2.5.1 to 2.6.0, from DevMode to SuperDevMode and -noserver, from Java 1.5 to 1.6 to 1.7, etc.) server-side changes show on the next run. What might be missing from a archetype generated project and/or from my Eclipse configuration that would cause server-side change to NOT take effect in Foo when they do elsewhere?

You could run Tomcat from within Eclipse (using WTP or similar) so that Eclipse automatically (or in a single click) redeploys your server-side code.
Or you could start Tomcat using the tomcat7-maven-plugin, it then scans the target/Foo-1.0-SNAPSHOT and automatically redeploys the app when there's a change (each time you save a file in Eclipse, so beware of memory leaks!)
Or you could point your external Tomcat to your target/Foo-1.0-SNAPSHOT (could be just a symlink), and redeploy your app "the Tomcat way" (which I have no idea what it is).
Or you could deploy your app to your Tomcat using the tomcat7-maven-plugin (just use -Dgwt.compiler.skip to skip GWT compilation)

I've had success with "mvn tomcat7:run", "mvn jetty:run" and pointing an external Jetty to my target/Foo-1.0-SNAPSHOT.
Reply all
Reply to author
Forward
0 new messages