Confused about RPC setup

[Neil Aggarwal]

Hello all:

I am trying to create stubs for RPC, but I am getting these errors from
the
GWT compiler:

[INFO] Compiling module com._3dmathpuzzles.play.Play
[INFO] Tracing compile failure path for type
'com._3dmathpuzzles.play.client.GetPuzzleService'
[INFO] [ERROR] Errors in
'file:/C:/OneDrive/Dev/3DMathPuzzlesWeb/src/main/java/com/_3dmathpuzzles/p
lay/client/GetPuzzleService.java'
[INFO] [ERROR] Line 15: No source code is available for type
com.propfinancing.puzzle.Puzzle; did you forget to inherit a required
module?
[INFO] Tracing compile failure path for type
'com._3dmathpuzzles.play.client.GetPuzzleServiceAsync'
[INFO] [ERROR] Errors in
'file:/C:/OneDrive/Dev/3DMathPuzzlesWeb/src/main/java/com/_3dmathpuzzles/p
lay/client/GetPuzzleServiceAsync.java'
[INFO] [ERROR] Line 13: No source code is available for type
com.propfinancing.puzzle.Puzzle; did you forget to inherit a required
module?
[INFO] Tracing compile failure path for type
'com._3dmathpuzzles.play.server.GetPuzzleServiceImpl'
[INFO] [ERROR] Errors in
'file:/C:/OneDrive/Dev/3DMathPuzzlesWeb/src/main/java/com/_3dmathpuzzles/p
lay/server/GetPuzzleServiceImpl.java'
[INFO] [ERROR] Line 13: No source code is available for type
com.google.gwt.user.server.rpc.RemoteServiceServlet; did you forget to
inherit a required module?
[INFO] [ERROR] Line 19: No source code is available for type
com.propfinancing.puzzle.Puzzle; did you forget to inherit a required
module?
[INFO] [ERROR] Errors in
'file:/C:/OneDrive/Dev/3DMathPuzzlesWeb/src/main/java/com/_3dmathpuzzles/p
lay/client/GetPuzzleService.java'
[INFO] [ERROR] Line 15: No source code is available for type
com.propfinancing.puzzle.Puzzle; did you forget to inherit a required
module?
[INFO] Finding entry point classes
[INFO] [ERROR] Hint: Check that the type name
'com.propfinancing.puzzle.Puzzle' is really what you meant
[INFO] [ERROR] Hint: Check that your classpath includes all required
source roots

My class com.propfinancing.puzzle.Puzzle is in a jar file on the
classpath. I added a Puzzle.gwt.xml with this content:

<module>
<inherits name="com.google.gwt.user.User"/>
<entry-point class="com.propfinancing.puzzle.Puzzle"/>
<source path=""/>
</module>

And made sure it is included in the jar.

The error about RemoveServiceServlet is strange since it is part of GWT.
I am not sure what I am doing wrong
on that.

I have been reading the docs and tutorials, but am not figuring this out.
I appreciate any guidance you all can offer.

Thank you,
Neil

--
Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
We offer 30 year loans on single family houses!

[Leon Pennings]

HI Neil,

the sourcecode is necessary for the GWT compilation from java to javascipt/html. Either the class to be compiled must be inside the 'client' part of the module setup - so in the packages that define the client code. Or if it is a dependency from another module/package, the source code needs to be available for the GWT compiler. So it needs a sources.jar during compilation. Runtime these are not required.

Also take care that whatever sources you include for the GWT compile only uses supported java code constructs that are supported in the GWT compile.

rg,

Leon..

Op zaterdag 14 december 2024 om 17:05:24 UTC+1 schreef Neil Aggarwal:

[Neil Aggarwal]

> it needs a sources.jar during compilation.

Got it. I added a sources jar but now I am getting many errors about
Log4j, getResourceAsStream, BufferedImage, etc.

So, obviously, my code refers to a bunch of stuff that is standard to Java
but it outside the scope of GWT.

I think I might have to write pared-down versions of my data classes just
for GWT or is there a better way to do it?

[Colin Alworth]

A common approach is to have three sets of types: "client", "server", and "shared'. The "client" and "server" are self-evident - these are types that exclusively belong to one runtime, and will never cross over to the other. Shared can be trickier - it must only use other shared types, or types/members that both GWT and JVM can handle.

In turn, both "client" and "server" code can depend on "shared" code.

Historically, projects have been advised to use packages separating their classes into these three categories. Typically they would all be in the same base package, with the .gwt.xml module file as a sibling. That .gwt.xml file then would have

<source path="client" />

<source path="shared" />

to make this relationship explicit.

For at least the last 10+ years while Maven (and later Gradle) were growing in popularity, it has instead been suggested to actually split projects, so you have a shared project, and the client and server projects depend on shared. (Getting off-topic, but following through in the idea: The server project then typically depends on the client JS output, but not the client classes themselves.) This makes it easier to directly control the dependencies of that shared project, and avoid surprising yourself by having server code that depends on client classes, enforcing this separation.

GWT-RPC isn't for everyone, though I happen to like it. The above advice is not exclusive to GWT-RPC, but can let you handle sharing business logic between JVM/browser runtimes. There are no specific extra rules to follow when applying to GWT-RPC, since the serialization mechanism is intended to roughly mirror java.io.ObjectOutputStream and friends - mark fields as transient to have them be skipped over, other fields on serializable types will be serialized. Data-Transfer Objects (DTOs) are a popular way to isolate serialized data from business logic, and while it isn't a requirement, you might find it to be a natural conclusion of the above suggestions.

Finally there are some "tricks" you can do to get a different implementation of a type using @GwtIncompatible or super source, though any solution that requires two implementations of a type should be scrutinized to see if there's a better way to handle it. You'll find examples on stackoverflow, other public gwt codebases, or the mailing list, but if you can give more specifics we can give examples that may help shed light on your problem.

[Neil Aggarwal]

> but if you can give more specifics we can give examples that may help shed
> light on your problem.

My goal is very specific:

If you go to this URL:
https://3dmathpuzzles.com/puzzles/DiagonalSlitherlink/Challenging/DiagonalSlitherlink-00001-3.pdf
You will get a PDF file of a puzzle I created.

I would like to create an interactive interface to solve the puzzle online.

For example, this is an interactive interface for solving Sudoku puzzles on
a different site:
https://krazydad.com/play/sudoku/

[Neil Aggarwal]

This might be another problem. My class structure is very involved.

For example, the storage object for my Diagonal Slitherlink is:

com._3dmathpuzzles.slitherlink.RectangularWithDiagonalsPuzzle
extends com.propfinancing.puzzle.slitherlink.RectangularWithDiagonalsPuzzle

Now, looking at its superclass:

com.propfinancing.puzzle.slitherlink.RectangularWithDiagonalsPuzzle
extends com.propfinancing.puzzle.slitherlink.RectangularPuzzle

Continuing on:

com.propfinancing.puzzle.slitherlink.RectangularPuzzle
extends com.propfinancing.puzzle.slitherlink.Puzzle

com.propfinancing.puzzle.slitherlink. Puzzle
extends com.propfinancing.puzzle.Puzzle

And finally:

com.propfinancing.puzzle.Puzzle is an abstract class which implements
Serializable.

I GWT going to handle a very involved inheritance hierarchy?

[Leon]

Inheritance is not a problem - atleast I never experienced any, just make sure you are only using the supported classes (@See https://www.gwtproject.org/doc/latest/RefJreEmulation.html) in the GWT client code and you should be fine.

Using maven modules to keep a clear overview of which code you can use feels a bit overkill to me.

A web module is a web module, I don't see any functional reasoning to split a web module into multiple maven modules.

GWT has some basic rules to keep in mind when implementing and they are quite simple -> Don't use servercode on the clientside. The serverside can use any client code, as long as it doesn't have to instantiate a GWT client side object.

Using to maven modules to keep that distinct line to me feels like using a bulldozer to swat a fly.

But hey, to each his own..

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/phc0Ajr7HFY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/7c137e8a79dacdb094ffc495f6b1313e%40mail.gmail.com.

[Neil Aggarwal]

> Inheritance is not a problem

Maybe what I can do is mark all the methods in my data classes with
GWTIncompatible. That way, the GWT compiler will see them as storage-only
classes.

[Leon]

I don't know your exact application, but why do you need to include those in the frontend?

What exactly do you do mean with storage?

The canvas is a great way to make fancy stuff. I've used it many times, but I only used the UI for presentation.

All (domain) logic I prefer to keep on the server, makes the UI a lot more straightforward and easier to manage.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/phc0Ajr7HFY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/8336e0ff562988d577a1163201a26786%40mail.gmail.com.

[Neil Aggarwal]

> I don't know your exact application, but why do you need to include those
> in the frontend?

I don't want to do a round-trip to the server every time the user takes an
action.
The UI will be faster if everything executes locally.

I want the front end to have an in-memory version of the puzzle so it will
update
and display the current state of the puzzle as the user is working on it.

[Leon]

Unless you have a shitty server or lots of concurrent of users, that roundtrip will not be a problem.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/phc0Ajr7HFY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/bf8ee8151f1c3d15dc8d9086409777fa%40mail.gmail.com.

[Tim Macpherson]

Your approach is similar to my apps: they use D3 diagrams which are initialised after rpc, after that they can be clicked indefinitely without another rpc.

Yahoo Mail: Search, Organize, Conquer

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/bf8ee8151f1c3d15dc8d9086409777fa%40mail.gmail.com.

[Neil Aggarwal]

> Unless you have a shitty server or lots of concurrent of users, that
> roundtrip will not be a problem.

Also, by doing updates on the client, I don’t have to manage concurrency and
keeping every user's state on the server.

To me, it seems like a better design choice.

[Neil Aggarwal]

> Your approach is similar to my apps: they use D3 diagrams which are initialised after rpc, after that they can be clicked indefinitely without another rpc.

It’s good to know someone else thinks the same way I do!

[Leon]

Well, there is no golden hammer that will fit any problem. You know your own application best.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/phc0Ajr7HFY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/92daa935899eb929051349349a308d63%40mail.gmail.com.

[Tim Macpherson]

There seems to have been a trend in the last few years to to keep UI logic in server side, especially Svelte. 

Yahoo Mail: Search, Organize, Conquer

--

You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit

https://groups.google.com/d/msgid/google-web-toolkit/dea5c99997b0e0bbf88403ed64ff1540%40mail.gmail.com

.

[Neil Aggarwal]

I just thought of another reason to do the logic on the client side:

I am using a CDN from Cloudflare to speed up the user experience.

I defeat its benefits if I put the logic on the server.

[Leon]

No, that's not a reason why you should go UI only. But it is also not relevant on whether it is or not. 

It's your own project, you can do with it whatever you want.

The only thing holding you back is not the software architecture. 

In the GWT ui part, there is no more java code after the gwt compilation.

 

All java code gets compiled into javascript & html. If you want to add another java library to the ui code, all java used in that library (and all dependencies in there) will need to be in the supported emulation library. (https://www.gwtproject.org/doc/latest/RefJreEmulation.html#Package_java_io)

Once that library has extra dependencies like awt or log4j, you are just screaming for trouble.

When you open a GWT application, all you have is static html + javascript content. Just like an ordinary html page. There is no access to server log files, or any other server resources after that (apart from gwt rpc calls, or any javascript library). 

GWT is not an application server, your UI compiled GWT code lives in the browser. 

And in my opinion, if you really want to use other javascript libraries from within GWT, then it does not make sense to use GWT. 

That's like hiring a German consultant to go shopping for French cheese.

--

You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/phc0Ajr7HFY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/e6f0787faa985852e8781b17e9dfd98f%40mail.gmail.com.

[Tim Macpherson]

Using a js library in gwt requires writing a
a native JsInterop class. In my apps that's very small as the detailed operations with the library are written in js 

Yahoo Mail: Search, Organize, Conquer

--

You received this message because you are subscribed to the Google Groups "GWT Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

To view this discussion visit

https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7SB--%2B%3DWTNZDiNtLwi-kBWQ1S%3Df62pnSzbMbCAH%3DEZ9wA%40mail.gmail.com

.

[Craig Mitchell]

In my car racing game, I do the logic on both client and server.  The player does the car race all in the browser, and at the end of the race, their inputs are sent to the server via GWT RPC, that then also runs the race logic, to make sure they didn't cheat.

GWT is fantastic for this.  The same code runs in both the client and the server.  Although, I have to be careful not to use things like floats, as they are floats in Java, but when compiled to JavaScript, they become doubles.

It's https://drift.team/ if interested.

[Neil Aggarwal]

> In my car racing game,

 

Wow, that is a nice game.  Very impressive!

 

Great idea to run it again on the server to prevent cheating.

 

So far, I am very impressed with GWT.  It is so nice to be able
to write only Java code instead of having the learn the nuances
of JavaScript.