GWT Developer Plugin no longer works with Chrome on Linux

[Magnus]

Hello,

after upgrading my Debian box (to jessie) I noticed that chrome (chromium) fails to install the GWT developer plugin:

"Sorry, the GWT Developer Plugin no longer works with Chrome on Linux"

Is this because people should use SuperDevMode instead? Well, I never managed to get SuperDevMode work, because I don't understand it's basic architecture and I was missing some detailed tutorial. So SuperDevMode now is the only development mode with GWT and Eclipse then I finally need a good tutorial, where all the steps are explained in detail. Can you recommend such a tutorial?

However, if support for the GWT developer plugin was not stopped intentionally, then what can I do to get it work with the newest chrome (chromium in jessie)?

Thanks
Magnus

[Jens]

https://stackoverflow.com/a/18333050/116472

-- J.

[Thomas Broyer]

Thanks Jens for the link ;-)

I just wanted to add that Manolo has been working this week on making it it easier to do the switch by making it (almost) as easy as DevMode (if not easier): just launch DevMode with an additional -superDevMode flag. This will ship in 2.7.

And Brandon has been working on adding support for SuperDevMode to the Google Plugin for Eclipse.

On Sunday, July 6, 2014 12:53:41 AM UTC+2, Jens wrote:

https://stackoverflow.com/a/18333050/116472

-- J.

[Magnus]

On Sunday, July 6, 2014 12:53:41 AM UTC+2, Jens wrote:

https://stackoverflow.com/a/18333050/116472

Thanks, but the "big picture" is still intransparent to me:

• compile and deploy your app to a web server near you
  What does this mean? I have a local machine, where I am developing, and a remote server. I am used to test on my local machine.
  Before SuperDevMode this was done by pointing to an eclipse menu entry: "run as web application".
  How should this be done now? Do you really have to "deploy" it, e. g. upload it with tomcat's manager application?
  
  
• Launch com.google.gwt.dev.codeserver.CodeServer with the same classpath that you'd launch DevMode with
  What does this mean? How can I "launch" this class? Do I have to create a Run Configuration in eclipse or something like that?
  
  
• If you never ran Super Dev Mode, go to http://localhost:9876
  What's this? Which application is running and listening there?
  
  

I believe that I am missing some additional knowledge to get SuperDevMode running with tutorials like this. I have tried it several times, without success. Please give some additional hints.

And what about the classical DevMode? Will it be unsupported by now and is this the reason why chrome fails to install the plugin?

Thanks

Magnus

[Thomas Broyer]

On Sunday, July 6, 2014 4:25:41 PM UTC+2, Magnus wrote:

On Sunday, July 6, 2014 12:53:41 AM UTC+2, Jens wrote:

https://stackoverflow.com/a/18333050/116472

Thanks, but the "big picture" is still intransparent to me:

Have you followed the link at the bottom of the answer?

http://blog.ltgt.net/how-does-gwts-super-dev-mode-work/

 

• compile and deploy your app to a web server near you
  What does this mean? I have a local machine, where I am developing, and a remote server. I am used to test on my local machine.
  Before SuperDevMode this was done by pointing to an eclipse menu entry: "run as web application".
  How should this be done now? Do you really have to "deploy" it, e. g. upload it with tomcat's manager application?
  

You can use "run as web application", or you can use Webby or Eclipse WTP to deploy it in a configured server (Tomcat or whatever), or you can package a WAR and deploy it to any server (Tomcat or whatever) you want. You could even deploy it to AppEngine or Heroku if you liked. It doesn't really matter: it's server-side code so GWT doesn't care.

In your case, I'd say: just keep using "run as web application", but just don't include the ?gwt.codesvr= in the URL to avoid triggering (classic) DevMode.

• Launch com.google.gwt.dev.codeserver.CodeServer with the same classpath that you'd launch DevMode with
  What does this mean? How can I "launch" this class? Do I have to create a Run Configuration in eclipse or something like that?
  

<snarky tone>How can you develop without knowing anything about your IDE?</snarky tone>

Maybe start here: http://help.eclipse.org/juno/topic/org.eclipse.jdt.doc.user/tasks/tasks-java-local-configuration.htm?cp=1_3_6_3

(that was the first result when I googled for "eclipse create run configuration")

• If you never ran Super Dev Mode, go to http://localhost:9876
  What's this? Which application is running and listening there?
  

The CodeServer you just launched at the previous step.

I believe that I am missing some additional knowledge to get SuperDevMode running with tutorials like this. I have tried it several times, without success. Please give some additional hints.

And what about the classical DevMode? Will it be unsupported by now and is this the reason why chrome fails to install the plugin?

Yes. Browsers have been removing the APIs and features that made DevMode possible. SuperDevMode also works in all browsers (except very old ones without localStorage support), including mobile ones.

 

[Henrik]

On Saturday, July 5, 2014 11:29:10 PM UTC+2, Magnus wrote:

I never managed to get SuperDevMode work, because I don't understand it's basic architecture and I was missing some detailed tutorial. So SuperDevMode now is the only development mode with GWT and Eclipse then I finally need a good tutorial, where all the steps are explained in detail.

A few weeks ago I spent most of two days getting SDM to work for a client (together with the Eclipse plugin and a multi-module maven-based project), but in the end we could come to no other conclusion that it was borderline unusable.  While it works from cmdline with maven, that really doesn't give you anything. 

Once working, the new thing of debugging directly in the browser certainly seemed cool at first, until you realize that in most cases you would rather have the java-view on your data.  It's not much fun trying to drill down a javascriptobject-representation of your arraylist or hashmap, for instance, while your IDE's default 'toString'-view is exactly what you would want. 

I would even be okay without any debugging options, if only the time from "you make a change" till "you see the change" would remain a one-step process (like a reload in the browser), and I don't see why this cannot be done.  Why not simply use a web-filter on any *.js files (or other relevant files) to automaticly check if the corresponding class-files have been changed on disk and if so, then recompile the necessary gwt-parts.  If the new compiler becomes more incremental (as I've seen mentioned in some presentations), then that should even be pretty fast, but more importantly, it would be a one-step thing. 

So at work, we still use Firefox with the automatic updates disabled for GWT-dev in good old DevMode.  It's hardly a long term solution, so I'm really anxious to see what happens with 2.7. 

Regards,

Henrik

[Thomas Broyer]

On Sunday, July 6, 2014 8:27:29 PM UTC+2, Henrik wrote:

On Saturday, July 5, 2014 11:29:10 PM UTC+2, Magnus wrote:

I never managed to get SuperDevMode work, because I don't understand it's basic architecture and I was missing some detailed tutorial. So SuperDevMode now is the only development mode with GWT and Eclipse then I finally need a good tutorial, where all the steps are explained in detail.

A few weeks ago I spent most of two days getting SDM to work for a client (together with the Eclipse plugin and a multi-module maven-based project), but in the end we could come to no other conclusion that it was borderline unusable.  While it works from cmdline with maven, that really doesn't give you anything. 

Once working, the new thing of debugging directly in the browser certainly seemed cool at first, until you realize that in most cases you would rather have the java-view on your data.  It's not much fun trying to drill down a javascriptobject-representation of your arraylist or hashmap, for instance, while your IDE's default 'toString'-view is exactly what you would want.

That sure would be cool. The problem is that it's simply no longer technically possible.

If you have the time and energy to build and maintain a browser fork with a working DevMode, go ahead; everyone will probably thank you. That would be just one browser though…

 

I would even be okay without any debugging options, if only the time from "you make a change" till "you see the change" would remain a one-step process (like a reload in the browser), and I don't see why this cannot be done.

It can: drag the "Compile" button to your bookmarks. That saves you the click on "DevMode On" so instead of click "reload", just click the "compile" bookmarklet.

Manolo has also been working on an easier way to launch SuperDevMode (just pass the -superDevMode argument to the DevMode) that also hosts the web application and doesn't require the bookmarks: there's a button in a corner instead, and a keyboard shortcut (Ctrl+K IIRC).

 

Why not simply use a web-filter on any *.js files (or other relevant files) to automaticly check if the corresponding class-files have been changed on disk and if so, then recompile the necessary gwt-parts.  If the new compiler becomes more incremental (as I've seen mentioned in some presentations), then that should even be pretty fast, but more importantly, it would be a one-step thing.

You could do that if you liked I believe (filter the host page; each time it's loaded, make the appropriate request to the CodeServer to trigger compilation), but sometimes reload the page without recompiling can be useful.

That means your webapp would have to be different in dev than in prod too, which generally adds complexity.

So at work, we still use Firefox with the automatic updates disabled for GWT-dev in good old DevMode.  It's hardly a long term solution, so I'm really anxious to see what happens with 2.7.

Did you know you can try it out now? 2.7.0-SNAPSHOT are deployed nightly at https://oss.sonatype.org/content/repositories/google-snapshots/ 

[Magnus]

Hi Thomas!

On Sunday, July 6, 2014 5:17:53 PM UTC+2, Thomas Broyer wrote:

 

Thanks, but the "big picture" is still intransparent to me:

 

Have you followed the link at the bottom of the answer?http://blog.ltgt.net/how-does-gwts-super-dev-mode-work/

No, thank you. I have not seen such a detailed explanation of SDM yet.

However, it's a long text with many interesting explanations, but it's missing a clear instruction: Simply what to do - where to click or whatever - to run your application during development.

I guessed what to do from the following sentence:

For now, you have to run your app in an HTTP server of your choice (Dev Mode is OK for the job), 

"Dev Mode is OK for the job". This told me that I could call "Run as Web Application" within eclipse. After this eclipse shows me an URL like this:

http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997

And this would produce the error message shown in my initial posting:

  

"Sorry, the GWT Developer Plugin no longer works with Chrome on Linux"

It's your comment that solved this:

In your case, I'd say: just keep using "run as web application", but just don't include the ?gwt.codesvr= in the URL to avoid triggering (classic) DevMode.

So I cut off this part in the URL and I at least got my application running again. This is a small success for me. I wonder why this is not clearly mentioned in all of those tutorials....

 

<snarky tone>How can you develop without knowing anything about your IDE?</snarky tone>

This may be off-topic, but developing means dealing with algorithms and data structures. From my previous point of view, the "IDE" plays a very minor role within the development process. But this seems to be different here and I am actually learning about it.

 

Maybe start here: http://help.eclipse.org/juno/topic/org.eclipse.jdt.doc.user/tasks/tasks-java-local-configuration.htm?cp=1_3_6_3

(that was the first result when I googled for "eclipse create run configuration")

For the moment, I am just happy to get my app running with the URL above:

http://127.0.0.1:8888/index.html

I cannot see why I need a run configuration. I can run my app, but I still don't know how to set breakpoints and do step-by-step debugging. But I can launch my app, because of your useful hint to not include "?gwt.codesvr" in my URL. This is missing in all of the turorials.

Thanks

Magnus

[Thomas Broyer]

On Monday, July 7, 2014 12:47:18 AM UTC+2, Magnus wrote:

For the moment, I am just happy to get my app running with the URL above:

http://127.0.0.1:8888/index.html

I cannot see why I need a run configuration. I can run my app, but I still don't know how to set breakpoints and do step-by-step debugging. But I can launch my app, because of your useful hint to not include "?gwt.codesvr" in my URL. This is missing in all of the turorials.

Except one: http://www.gwtproject.org/doc/latest/tutorial/compile.html#run 

[Magnus]

Hi,

thanks, after all, I am able to get my app running in whatever mode, I think it's Super Dev Mode...

• call eclipse's "Run as Web Application" command
  
• open the URL displayed by eclipse, but omit the "gwt.codesvr=127.0.0.1:9997" suffix
  

However, after changing some code, a simple reload does not bring the new version. Even a complete restart of the run command in eclipse does not bring the new version.

It's astonishing to me. I make a change in the code and I am unable to propagate this change into the running app. Even closing and reopening the project did not help!

Please remember that at the moment using Super Dev Mode means to me nothing more than leaving out the URL suffix mentioned above.

Magnus

[Thomas Broyer]

On Sunday, July 27, 2014 1:49:35 AM UTC+2, Magnus wrote:

Hi,

thanks, after all, I am able to get my app running in whatever mode, I think it's Super Dev Mode...

• call eclipse's "Run as Web Application" command
  
• open the URL displayed by eclipse, but omit the "gwt.codesvr=127.0.0.1:9997" suffix
  

However, after changing some code, a simple reload does not bring the new version. Even a complete restart of the run command in eclipse does not bring the new version.

It's astonishing to me. I make a change in the code and I am unable to propagate this change into the running app. Even closing and reopening the project did not help!

You're running in "prod mode". You need to recompile your app to see the results.

Compiling with "-draft" might be fast enough for you; it is for some: https://plus.google.com/109644308452607074535/posts/Ak5Fxz2R45h

GWT 2.7 will make it much easier to run SuperDevMode, if you can wait until then (or use the snapshots published on Sonatype OSSRH)

[Magnus]

Hi Thomas,

my GWT compiler does not recognize a "-draft" option. I am running GWT 2.6.0.

I remember some problems with GWT designer after upgrading GWT the last time, which forced me to go back to an older version. I think it was 2.6.0.

However, I changed my code (added a cell view into my split panel), but I do not see the result after recompiling. Maybe there was an error or an exception. Are exceptions still shown in eclipse when running SDM?

How can I debug step by step in SDM?

Thanks a lot,

Magnus

[Jens]

my GWT compiler does not recognize a "-draft" option. I am running GWT 2.6.0.

I think it is -draftCompile . Doesn't the GWT compiler help (which is automatically shown on console when you provide an unknown parameter) doesn't show the correct option?

However, I changed my code (added a cell view into my split panel), but I do not see the result after recompiling. Maybe there was an error or an exception. Are exceptions still shown in eclipse when running SDM?

Server exceptions are shown in your DevMode Jetty output and client exceptions are shown in the browser console and/or are handled by your GWT.setUncaughtExceptionHandler().

 

How can I debug step by step in SDM?

Using the browser's dev tools. For eclipse there is a proof-of-concept plugin to allow debugging in the IDE: https://github.com/sdbg/sdbg

-- J.

[Blake McBride]

I spent a little time many months ago trying to get SDM working.  I think I succeeded but was very surprised about the number of steps required.  The thing that surprised me most, however, was discovering that I had to have two servers running (if I am correct) - an app server, and a code server.  All of the docs I've seen provide the steps but never explain at a higher level what is going on (unless you understand far more internal details than many of us).  The biggest difficulty occurs because the instructions were leading me down the path of two servers but I kept fighting it - trying to get one server to perform both functions.  The fight occurred because I didn't understand what was being attempted.  I didn't understand that I needed two servers running.

So, what is needed is a better up-front description of what you end up with (two servers), and a block diagram that depicts the parts and the data flow between them.  Understanding this would make the instruction much more clear.

(Sorry if I am totally wrong and confused.  Quite possible.)

Thanks.

Blake

Blake McBride

www.arahant.com

Cell:    615-394-6760

Office:  615-376-5500

Fax:     615-377-6006

--
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-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

On Sunday, July 27, 2014 5:22:53 PM UTC+2, Blake McBride wrote:

I spent a little time many months ago trying to get SDM working.  I think I succeeded but was very surprised about the number of steps required.  The thing that surprised me most, however, was discovering that I had to have two servers running (if I am correct) - an app server, and a code server.  All of the docs I've seen provide the steps but never explain at a higher level what is going on (unless you understand far more internal details than many of us).  The biggest difficulty occurs because the instructions were leading me down the path of two servers but I kept fighting it - trying to get one server to perform both functions.  The fight occurred because I didn't understand what was being attempted.  I didn't understand that I needed two servers running.

So, what is needed is a better up-front description of what you end up with (two servers), and a block diagram that depicts the parts and the data flow between them.  Understanding this would make the instruction much more clear.

(Sorry if I am totally wrong and confused.  Quite possible.)

http://blog.ltgt.net/how-does-gwts-super-dev-mode-work/

Does that help?

[Blake McBride]

Embarrassing.  Yes, that is exactly what I was looking for.  I've seen the link but never followed it because I thought it was meant to go into highly technical details that I wasn't yet up to.

It is clear that a lot of people are having a lot of trouble with SDM.  There are a few good pages that contain valuable information on setting up SDM.  In spite of this, many people are still having a lot of trouble.  Perhaps I can propose this.  

1.  Create a single "master" SDM page.  Perhaps it would start with one of the already existing pages that tell a person how to setup SDM.

2.  The page would contain very detailed information on setting up and using SDM in eclipse, intelliJ, and NetBeans.

3.  It would contain links to all of the places this list points people to.

4.  It would be updated very often - even if the procedure hasn't changed.  Every time someone is confused with the instructions, rather than just answer them, the "master" page will get updated to clarify the point in question.

Every time some asks how to setup or use SDM, we can refer them to that single (root) page.  If we do this, that page will quickly evolve into a single source containing the most up-to-date, complete, and unambiguous instructions.

Just a thought.

Thanks.

Blake

[Thomas Broyer]

I think the goal is to eventually replace all mentions of DevMode in gwtproject.org with SuperDevMode with up-to-date information (now that DevMode is only usable in IE and GWTTestCase, but because of GWTTestCase we still need to talk about how code is executed in the JVM with a JS/JVM bridge, rather than compiled to JS).

From my POV, this would build on my blog post and StackOverflow answer.

…but note that in GWT 2.7 we introduce an easier way to run SDM with a single command-line, with the two servers in a single process (just like in DevMode, with an embedded Jetty server to host the webapp)

Feel free to propose patches to gwtproject.org if you have ideas (or just come discuss them on gwt-contrib); you have my permission to copy text from my blog post and StackOverflow answer.

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Manuel Carrasco Moñino]

Here you have a post about what is coming in eclipse to run superdev mode with just a click.

For inpatients, just use GWT-2.7.0-SNAPSHOT and include the gwt-codeserver.jar in your project classpath,  run dev mode as usual in your project, and finally edit the launcher configuration and add the -superDevMode parameter.

- Manolo

--

[Manuel Carrasco Moñino]

Forgot the link to the post: http://www.sencha.com/blog/getting-started-with-gwt-super-dev-mode

[Magnus]

How can I debug step by step in SDM?

Using the browser's dev tools. For eclipse there is a proof-of-concept plugin to allow debugging in the IDE: https://github.com/sdbg/sdbg

Do the two sentences indicate two debugging methods? 

If so, what are the browser's dev tools?

If not: Why is there a big switch (chrome does not support devmode plugin anymore), allthough debugging is still in "proof-of-concept" stage?

(I have taken a look at it, but at the moment I need a reliable debugging method.)

However, I am doing my first steps in SDM, but I cannot solve the simplest problems:

For example, there is a wrong SQL statement in my server code, but I cannot analyze it. There is simply a never ending loading indicator in my cell list, but without being able to do step by step debugging I cannot solve this.

Magnus 

[Magnus]

I cannot even debug by "tracing", i. e. do some System.out.println commands. I cannot see any output.

Magnus

[Vassilis Virvilis]

For server side code you can use your standard logging facilities. I understand that may tedious to get right log4j vs slf4j vs commons logging vs java.util.logging but it is standard plumbing in every project.

I am using only logging for debugging in server side but AFAIK you can do step by step in eclipse with tomcat. I don't know about jetty.

   Vassilis

--

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-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Vassilis Virvilis]

It's console.log to send it to browser's console (F12 opens the browser's dev tools usually). Check http://www.gwtproject.org/doc/latest/DevGuideLogging.html

 Vassilis

On Sun, Aug 3, 2014 at 10:03 AM, Magnus <alpine...@gmail.com> wrote:

I cannot even debug by "tracing", i. e. do some System.out.println commands. I cannot see any output.

Magnus

--

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-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Jens]

Using the browser's dev tools. For eclipse there is a proof-of-concept plugin to allow debugging in the IDE: https://github.com/sdbg/sdbg

Do the two sentences indicate two debugging methods? 

When you use SDM you have your app compiled to JavaScript running in your browser and you have your server side code deployed on tomcat/jetty/whatever.

To debug the JavaScript in your browser you can either use your browsers dev tools or try using the experimental SDBG plugin for eclipse. When you use your browsers dev tools then you have to set breakpoints inside the browser, when you use SDBG you can set them in eclipse. It is important to understand that in both cases you are debugging JavaScript and not Java. With the help of SourceMaps (supported in IE11, FF, Chrome and I think latest Opera) the JavaScript will be mapped back to Java statements so you can more easily understand which Java code corresponds to the JavaScript code.

To debug the server side of your app, simply launch your app server in debug mode and then attach to it using your IDE. If you use the embedded Jetty of classic DevMode as your server it is as easy as choosing "debug as web application". Then you can set breakpoints in Eclipse in your server side code and debug as usual. There is no difference to classic DevMode or better classic Java debugging.

If so, what are the browser's dev tools?

Each browser lets you debug JavaScript:

- Chrome: https://developer.chrome.com/devtools/index

- Firefox: https://developer.mozilla.org/en-US/docs/Tools (even though the site states to install Aurora, the FF dev tools are already available in FF. Alternatively you can install the FireBug extension)

- IE: http://blogs.msdn.com/b/ie/archive/2013/07/29/debugging-and-tuning-web-sites-and-apps-with-f12-developer-tools-in-ie11.aspx

 

However, I am doing my first steps in SDM, but I cannot solve the simplest problems:

For example, there is a wrong SQL statement in my server code, but I cannot analyze it. There is simply a never ending loading indicator in my cell list, but without being able to do step by step debugging I cannot solve this.

As said above, to debug your server code just launch your server in Debug mode and then use your IDE as usual to set break points. If you also want to step through client side code you have to do that in the browser dev tools or using SDBG.

-- J.

[Jens]

I cannot even debug by "tracing", i. e. do some System.out.println commands. I cannot see any output.

On client side use GWT.log or the GWT emulation of java.util.logging (http://www.gwtproject.org/doc/latest/DevGuideLogging.html).

Both log to your browser console.

-- J.

[Magnus]

To debug the JavaScript in your browser you can either use your browsers dev tools or try using the experimental SDBG plugin for eclipse. When you use your browsers dev tools then you have to set breakpoints inside the browser, when you use SDBG you can set them in eclipse. It is important to understand that in both cases you are debugging JavaScript and not Java.

Indeed, when I open the dev tools in chrome (F12) and go to the "Sources" tab, I can open a lot of JS code and I can set breakpoints there. But I cannot see which JS code corresponds to the Java code that I want to analyze.

Even if I compile in "pretty" mode, I cannot see any correspondence. I think you have to know JS

 

With the help of SourceMaps (supported in IE11, FF, Chrome and I think latest Opera) the JavaScript will be mapped back to Java statements so you can more easily understand which Java code corresponds to the JavaScript code.

How does this work? Can you open Java sources and set breakpoints there then?

Is this the preferred way of debugging GWT code in SDM?

Will the eclipse integrated debugging return with a later GWT version?

 

Thanks

Magnus 

[Thomas Broyer]

On Sunday, August 3, 2014 11:56:49 PM UTC+2, Magnus wrote:

To debug the JavaScript in your browser you can either use your browsers dev tools or try using the experimental SDBG plugin for eclipse. When you use your browsers dev tools then you have to set breakpoints inside the browser, when you use SDBG you can set them in eclipse. It is important to understand that in both cases you are debugging JavaScript and not Java.

Indeed, when I open the dev tools in chrome (F12) and go to the "Sources" tab, I can open a lot of JS code and I can set breakpoints there. But I cannot see which JS code corresponds to the Java code that I want to analyze.

This is because you need Source Maps. It's possible to get them to work in "prod mode", as can be seen on gwtproject.org, but it requires few tricks at build and packaging time. The easiest way is to use Super Dev Mode, which sets everything up automatically.

A quick note: on gwtproject.org, open Chrome dev tools, go to the Sources tab, hit Ctrl+O and select GWTProjectEntryPoint.java. You can then set breakpoints in the Java code and see them being hit (some might require you reload the page).

 

Even if I compile in "pretty" mode, I cannot see any correspondence. I think you have to know JS

Let's be honest: if you think you can build a web app without knowing JS, you're lying to yourself.

You can do many things with GWT without knowing JS, but you'll eventually have to know about it.

 

 

With the help of SourceMaps (supported in IE11, FF, Chrome and I think latest Opera) the JavaScript will be mapped back to Java statements so you can more easily understand which Java code corresponds to the JavaScript code.

How does this work? Can you open Java sources and set breakpoints there then?

Yes.

 

Is this the preferred way of debugging GWT code in SDM?

Yes (not only the "preferred way", but The way)

 

Will the eclipse integrated debugging return with a later GWT version?

DevMode won't come back in browsers that killed support for it.

But if you're looking for Eclipse integration (rather than running Java code in the JVM rather than compiled to JS), then have a look at SDBG. https://sdbg.github.io/

In any case, you won't get "watch expressions" (or similar) working.

[Magnus]

On Monday, August 4, 2014 1:19:11 AM UTC+2, Thomas Broyer wrote:

On Sunday, August 3, 2014 11:56:49 PM UTC+2, Magnus wrote:

Indeed, when I open the dev tools in chrome (F12) and go to the "Sources" tab, I can open a lot of JS code and I can set breakpoints there. But I cannot see which JS code corresponds to the Java code that I want to analyze.

This is because you need Source Maps. It's possible to get them to work in "prod mode", as can be seen on gwtproject.org, but it requires few tricks at build and packaging time. The easiest way is to use Super Dev Mode, which sets everything up automatically.

You're talking about "prod mode" and "Super Dev Mode". Which mode is what I am running here?

Remember where I am standing:

In eclipse I call "run as web application", and in the generated link (http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997) I cut off the portion after and including the "?" character, which results in http://127.0.0.1:8888/index.html.

This and nothing more is what I have changed. I thought that I am using SDM this way. If this is not SDM, what do I have to change to use SDM?

Thanks

Magnus

[Jens]

Remember where I am standing:

In eclipse I call "run as web application", and in the generated link (http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997) I cut off the portion after and including the "?" character, which results in http://127.0.0.1:8888/index.html.

This and nothing more is what I have changed. I thought that I am using SDM this way. If this is not SDM, what do I have to change to use SDM?

It will be SDM if you have compiled your app to JavaScript beforehand so you can access it through http://127.0.0.1:8888/index.html and if you have used the DevMode On bookmarklet from the SDM code server afterwards to recompile your app (and thus reloading the app from the SDM code server, which also provides sourcemaps, automatically).

If you have never used the bookmarklet then you haven't used SDM yet. In that case you probably only have compiled your app to JavaScript and used the embedded Jetty of classic DevMode (run as web application) to serve your app.

-- J.

[Magnus]

On Monday, August 4, 2014 8:57:32 PM UTC+2, Jens wrote:

Remember where I am standing:

In eclipse I call "run as web application", and in the generated link (http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997) I cut off the portion after and including the "?" character, which results in http://127.0.0.1:8888/index.html.

This and nothing more is what I have changed. I thought that I am using SDM this way. If this is not SDM, what do I have to change to use SDM?

It will be SDM if you have compiled your app to JavaScript

Yes, I run the GWT compiler...

 

so you can access it through http://127.0.0.1:8888/index.html

Yes, I cann access it this way!

 

and if you have used the DevMode On bookmarklet from the SDM code server afterwards to recompile your app (and thus reloading the app from the SDM code server, which also provides sourcemaps, automatically).

I remember having created this bookmarklet when reading some SDM document, but I never understood how to use it. Why should one use it to recompile the app, instead of running the GWT compiler in eclipse? And what exactly is the SDM code server (remember, I started my app in eclipse by calling "run as web application"). Is it simply the embedded server in eclipse called Jessie?

However, when I click on the "DevMode On" bookmarklet while my app is running, I get the following message in the chrome console:

GET http://localhost:9876/dev_mode_on.js net::ERR_CONNECTION_REFUSED

If you have never used the bookmarklet then you haven't used SDM yet.

No, I never used the bookmarklet, because I did not see any effects.

 

In that case you probably only have compiled your app to JavaScript and used the embedded Jetty of classic DevMode (run as web application) to serve your app.

Should the app be started in a different way, other than "run as web application"?

 

My understandig at the moment looks like this:

1. Run "GWT compile" in eclipse.
   
2. Run "Run as Web Application" in eclipse.
3. Open "http://127.0.0.1:8888/index.html" in the browser
4. Make changes to the code, because you saw that there is something wrong.
5. Click on "DevMode On".

As already mentioned, 5. does not work for me. I don't understand why we don't simply recompile with "GWT compile" command in eclipse. And I also don't understand 1. and 2.: Calling "Run as Web Application" always worked without running the GWT compiler. I always needed the GWT compiler to create a war file...

I hope that I get the breakthrough soon...

Magnus

[Jens]

I remember having created this bookmarklet when reading some SDM document, but I never understood how to use it. Why should one use it to recompile the app, instead of running the GWT compiler in eclipse? And what exactly is the SDM code server (remember, I started my app in eclipse by calling "run as web application"). Is it simply the embedded server in eclipse called Jessie?

The code server is a process that uses the GWT compiler to recompile your app and serve the output (including SourceMaps) using an embedded Jetty server. The benefit is that the code server will configure the GWT compiler for maximum performance (by disabling all kinds of optimizations). Also the code server can hold the GWT compiler instance in memory to cache certain information and thus saving some work which also reduces compilation time. Caching will have an even greater effect once incremental compilation is supported.

Basically the code server should be faster at recompiles than if you would start the GWT compiler by hand in eclipse. Well and SourceMaps usually just work.

 

However, when I click on the "DevMode On" bookmarklet while my app is running, I get the following message in the chrome console:

GET http://localhost:9876/dev_mode_on.js net::ERR_CONNECTION_REFUSED

Thats because you never started the code server. Actually the Google Eclipse plugin has no built-in support for SDM so you have to start it manually using a Java Application run configuration or some build tool like maven/gradle. GWT 2.7 will make it a lot easier to launch the code server. To launch the code server manually put code-server.jar from your GWT SDK on class path and use com.google.gwt.dev.codeserver.CodeServer as main class. The class path for the code server should be the same as for classic DevMode and command line parameters are similar.

 

In that case you probably only have compiled your app to JavaScript and used the embedded Jetty of classic DevMode (run as web application) to serve your app.

Should the app be started in a different way, other than "run as web application"?

No thats fine if thats all you need.

 

 My understandig at the moment looks like this:

1. Run "GWT compile" in eclipse.
   
2. Run "Run as Web Application" in eclipse.
3. Open "http://127.0.0.1:8888/index.html" in the browser
4. Make changes to the code, because you saw that there is something wrong.
5. Click on "DevMode On".

As already mentioned, 5. does not work for me. I don't understand why we don't simply recompile with "GWT compile" command in eclipse.

 

You can use GWT compile in eclipse but then you have to make SourceMaps work. Also the code server should recompile faster (see above).

 

And I also don't understand 1. and 2.: Calling "Run as Web Application" always worked without running the GWT compiler. I always needed the GWT compiler to create a war file...

Run as Web Application has started classic DevMode and an embedded Jetty server to serve your server side code. Classic DevMode was then responsible to execute your code. Now you don't use classic DevMode so the only way to execute your app is to compile it to JavaScript so that the browser can execute it.

-- J.

[Magnus]

Hi,

thank you, good explanation!

I think I got it now. The code server is running and I am able to run my app.

But there is one limitation: I cannot see my sources! According to a howto that I found on the web, the sources should be displayed in chrome dev tools under "localhost", but I don't see them.

In the run configuration, I used the java arguments from the howto:

-bindAddress 0.0.0.0  mcs.mcs

I also added my src folder to the classpath.

When I run it, the console looks like this:

workDir: /tmp/gwt-codeserver-2052393959063966034.tmp

binding: user.agent=safari

binding: compiler.useSourceMaps=true

binding: locale=en

Compiling module mcs.mcs

   Compiling 1 permutation

      Compiling permutation 0...

      Source Maps Enabled

   Compile of permutations succeeded

Linking into /tmp/gwt-codeserver-2052393959063966034.tmp/mcs.mcs/compile-1/war/mcs; Writing extras to /tmp/gwt-codeserver-2052393959063966034.tmp/mcs.mcs/compile-1/extras/mcs

   Link succeeded

   Compilation succeeded -- 21.933s

Compile completed in 22878 ms

2014-08-07 05:30:53.171:INFO:oejs.Server:jetty-8.y.z-SNAPSHOT

2014-08-07 05:30:53.228:INFO:oejs.AbstractConnector:Started SelectChann...@0.0.0.0:9876

The code server is ready.

Next, visit: http://magnus:9876/

Then I open http://magnus:9876/.

To start my app, I tried two different methods found on the web:

• Open the index.html file on the local file system by entering "file:///<path>/index.html in the URL field
• Calling "Run as Web Application" in eclipse (thus, starting a second process in eclipse, seems to work)

But in both cases, I don't see my sources:

Here's my module.xml:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.6.0//EN"

  "http://google-web-toolkit.googlecode.com/svn/tags/2.6.0/distro-source/core/src/gwt-module.dtd">

   

<module rename-to='mcs'>

  <inherits name='com.google.gwt.user.User'/>

  <inherits name='com.google.gwt.user.theme.clean.Clean'/>

 

  <inherits name='awi'/>

  <entry-point class='mcs.client.Application'/>

  <source path='client'/>

  <source path='shared'/>

  <!-- Super Dev Mode -->

 

  <add-linker name="xsiframe"/>

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

  <set-property name="compiler.useSourceMaps" value="true" />

  

  <!-- debug -->

  

  <set-property name="compiler.stackMode" value="emulated" />

  <set-configuration-property name="compiler.emulatedStack.recordLineNumbers" value="true" />

  <set-configuration-property name="compiler.emulatedStack.recordFileNames" value="true" />

  

</module>

Thank you,

Magnus

[Jens]

In GWT 2.6.x devModeRedirectEnabled is enabled by default, so you can remove it from your module. Because it is enabled by default GWT restricts SDM to 127.0.0.1 and localhost for security. If you need to access your app through "myhost" then you have to whitelist that host explicitly using <set-configuration-property name="devModeUrlWhitelistRegexp" value="....">.

In the future, with GWT 2.7, you can also remove the xsiframe linker because that will be the new default.

-- J.

[Magnus]

I understand that by default only localhost is supported. This would be sufficient for me.

I want to stay on my local machine, so that no white listing is necessary.

However, when starting SDM the console writes:

The code server is ready.

Next, visit: http://magnus:9876/

I don't need "magnus" here, but I also don't want to change /etc/hostname.

I tried to simply access the code server with

http://localhost;:9876/

But no source code.

What can I do, so that I can run everything on my local machine?

Magnus

PS: I also tried devModeUrlWhitelistRegexp with "http://magnus", but this also did not work, maybe a wrong regexp or so...

[Magnus]

I removed the -bindAddress 0.0.0.0 option and now the code server says:

The code server is ready.

Next, visit: http://localhost:9876/

I guess that now no devModeUrlWhitelistRegexp option should be necessary.

Compiled wit GWT compiler, started code server, started app, but still no source code.

Magnus

[Magnus]

Finally, it works for me!

It seems to be normal that there is no source code at the beginning, not before a click on "DevMode On".

In addition, after a while the Bookmarklet "DevMode On" did not work anymore. I struggled with this problem until I deleted recreated them by dragging them onto my bookmarks bar from the code server's starting page again. It seems as if the code behind the bookmarklets is different in every session?

However, now I can set breakpoints in chrome and debug step by step. Rock'n Roll!!! :-)

Magnus