Debug Doesn’t Work After Migrating SmartGWT from v4.0 to v13.0.

[norida.olivera]

I have a test environment with the BuiltInDs project that uses the following components:
JDK 1.8
SmartGWT Eval v13.0-p20221103
GWT 2.8.2
Maven 3.8.6

And to run it I use the following targets:








With this configuration, I can access Developer Mode for debugging the code and it works correctly.

On the other hand, I have an environment with a real project that uses the following components:
JDK 1.8
SmartGWT Pro v4.0
GWT 2.8.0
Maven 2.0

And I run it using the following goals:





With those goals I can access the Developer Mode for debugging the code and it works correctly.

Now, when I migrate the productive project to the SmartGWT v13.0-p20221103 version with GWT 2.8.2, the same Maven 2.0 and JDK 1.8, with the same goals that worked in the project without migration, the goals are executed correctly and I can activate the Developer Mode, but the debugging has no effect; moreover, in the console, only a trace similar to this one appears:

[oscarlondoņo]

Hi, Isomorphic.

Do you have any comments on this?

[oscarlondoņo]

Hi, Isomorphic.

We are trying to migrate SmartGWT from version 4.0 to 13.0; During this process we open a report that has a detail which uses a listGrid, but the report is blocked. We wanted to do debugging, but when trying to activate the DevMode and start debugging, it didn't work (as mentioned in the first post, in 4.0 it could be done without problem).

Enabling this debugging mode is essential, for us to be able to review why the report doesn't work (and for other tasks in the future); but it is also important, to be able to finish the migration and proceed to acquire the SmartGWT v13.0 license.

We appreciate any help you can give us in resolving the blockage with debugging configuration. If you need us to send you any files or information you consider relevant, we will gladly share it.

Thanks!

[Isomorphic]

Now, when I migrate the productive project to the SmartGWT v13.0-p20221103 version with GWT 2.8.2, the same Maven 2.0 and JDK 1.8, with the same goals that worked in the project without migration, the goals are executed correctly and I can activate the Developer Mode, but the debugging has no effect; moreover, in the console, only a trace similar to this one appears:

Maven 2.0 was released in 2005 and is long out of support. Can you reattempt your migration with a currently supported version of Maven? No one else has reported to us a problem with using SmartGWT 13.0 with recent versions of Maven and GWT. There is an incompatibility between the most recent versions of Eclipse and the GWT Eclipse Plugin, but that's not what you're reporting.

[norida.olivera]

Hi isomorphic.

We updated maven to version 3.8.7, as you recommended, but it still has the same behavior:



When enabling DevMode, it shows this in the console:





When trying to access to the page, it shows this in the console:



Whould you please guide us with something else that we can check?

[Isomorphic]

As we said, this hasn't been reported to us by anyone else, so it may just be that there's a misconfiguration somewhere in your settings, etc.

With regard to the double-loading of modules, we have seen that happen in certain situations before. Are you able to use the GWT Plugin in your version of Eclipse? (GWT Development Mode (DevMode))? If you're able to use that launcher, try first running with the "Legacy Development Mode" radio button selected in the GWT tab. You don't need to open it (since it requires a very old browser), so just run the build. Then switch to "Super Development Mode" and rerun the launch configuration. This should correct any issue and allow you to debug with code maps.

The other suggestion is to look at the results of putting "can't find any gwt modules on this page" into your favorite search engine. This produces some interesting results, such as this.

[Isomorphic]

Note that, if you can't find what's wrong with your project with these incremental approaches, the surefire approach is to take one of the sample Maven projects, set it up and verify debugging is working, then add the resources from your application to that.

With this approach, you are sure to get rid of whatever bad configuration is causing your pre-existing project to fail.

[norida.olivera]

Hi isomorphic.

As you recommended, we created a basic Maven project based on the BuiltInDs archetypes, using SmartGWT 13.0, JDK 1.8 and GWT 2.8.2; We also validated that the DevMode worked correctly for debugging on the client side.

Once we had this basic environment working, we started migrating the modules of our project, one by one, to the basic project, validating that both the application and the DevMode execution continued to work correctly.

Finally, we add the packages related to the client side and those that contain classes with RPC calls, (something that in the project that uses SmartGWT 4.0, JDK 1.8 and GWT 2.8.0, generated their Async classes automatically and without problem), it shows us this error “Missing asynchronous interface <Remote Service Name>Async”, as shown in the images below:





We are aware of your recommendation against using GWT -RPC, but our application has several of those calls that we must migrate and we would like to know how to solve it: if it is some configuration that we are missing in the web.xml or in the .gwt.xml, even if it is due to some Maven dependency that we must consider.

[Isomorphic]

We know very little about GWT-RPC because it's just not a good approach. However, we can Google the error message:

https://livebook.manning.com/book/gw.../chapter-7/145

Excerpt:

WHY DOES ECLIPSE SHOW “MISSING ASYNCHRONOUS INTERFACE”?


If you’re developing the application using GPE, Eclipse will report the error “Missing asynchronous interface TwitterServiceAsync.” The reason is that the plug-in is anticipating that you also need to create a client-side asynchronous interface

[Isomorphic]

A guess is that those interfaces used to be generated for you at build time by the (legacy) Mojo Maven plugin For GWT. That plugin has for a long time “strongly encouraged" the use of the TBroyer Maven Plugin for GWT instead for new development. Our archetypes are all set up that way, so that's probably what you're using now if you’re starting with the BuiltInDS example - but the TBroyer plugin doesn't include a similar goal for interface generation (and we wouldn’t illustrate it anyway, for obvious reasons).

You could in theory reconfigure the project to use the old Mojo plugin instead of the new TBroyer plugin. That would likely be much more trouble than its worth though, especially if all that’s needed is the missing generateAsync goal. The most obvious alternatives are:

1. Create and maintain the missing interfaces by hand
2. Allow Eclipse to generate the interfaces for you, as outlined in the GWT RPC tutorial:
   

   Right click on the error in Eclipse, select Quick Fix, and choose the “Create asynchronous RemoteService interface” option to automatically generate the asynchronous interface.

3. Use the AutoRPC GWT Generator project (recommended by the Mojo plugin for replacing generateAsync) to generate the interfaces for you at build time.

We would generally recommend option 2 or 3, with a strong preference for option 2 accompanied by a migration away from GWT-RPC altogether. Also take a few minutes to review both the TBroyer tips for migration away from Mojo and current Eclipse plugin doc if you aren't already familiar with both. It might save some trouble going forward.