Re: Digest for google-web-toolkit@googlegroups.com - 12 updates in 3 topics

[Leon]

One thing that is also quite relevant when developing a GWT application is to realize that all GWT generated code lives in the browser and that browser caching can be a problem. Whenever you do a GWT compile and want to check the result in the browser, make sure to clear the cache first because the old code will very likely not be reloaded.

I always have the developer mode in the browser open when developing and never click reload, but always 'empty cache and hard reload'. You will need it a lot.

The same goes for server updates. Best to do them late in the day or early in the morning, so users can't have stale code in their browsers. 

Either that, or learn them to do the hard reload (but you can also try and learn dogs to fly, that might have the same level of success).

Neil, I think you are trying to learn GWT in the hardest way possible. 

GWT is a way to develop a UI using java, but it is not run as java, and at runtime will not have the same possibilities as java. 

So it has its limitations when compared to what you can do with java on the server.

When you've developed something for standard java to work, based on all available libraries and known server possibilities, which you want to port to GWT is like trying to port a sportscar into a tractor. It's not impossible, but it is quite the challenge.

On Thu, Dec 19, 2024 at 9:56 PM <google-we...@googlegroups.com> wrote:

google-we...@googlegroups.com

Google Groups

Topic digest
View all topics

• Class not included in the set of types for RPC - 4 Updates
• Digest for google-we...@googlegroups.com - 18 updates in 5 topics - 2 Updates
• Getting 500 error from RPC call - 6 Updates

Class not included in the set of types for RPC

Neil Aggarwal <ne...@propfinancing.com>: Dec 18 10:45PM -0600 I am getting this error on the server: Type 'com.propfinancing.puzzle.slitherlink.Line' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be serialized.: instance = Line 0   And looking in the .gwt.rpc file, it is not listed there.   Interestingly, I see this: com.propfinancing.puzzle.slitherlink.Line$STATUS which is an Enum in that class so the GWT compiler obviously processed the class.   I did not get any warnings or error messages from the GWT compiler as to why it decided it did not like the class so now I have to guess what it did not like.   Is there a way to improve the messaging to the user to help understand what happened?   Thank you, Neil   -- Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer 30 year loans on single family houses!

Craig Mitchell <ma...@craig-mitchell.com>: Dec 18 11:08PM -0800 At a guess, the inner enum needs to be told it can be serialised. Ie:   import com.google.gwt.user.client.rpc.IsSerializable;   enum STATUS implements IsSerializable { ... }   On Thursday, 19 December 2024 at 3:46:31 pm UTC+11 Neil Aggarwal wrote:

Colin Alworth <co...@colinalworth.com>: Dec 19 06:19AM -0800 Enums never need to be marked as serializable - unlike records, the Enum type itself is always serializable, and GWT-RPC assumes the same. From https://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGuideSerializableTypes   A type is serializable and can be used in a service interface if one of the following is true: ... * The type is an enumeration. Enumeration constants are serialized as a name only; none of the field values are serialized.     That error message is indeed what is used when the standard serialization policy is read from disk, so you've resolved that earlier issue. Can you confirm that the policy file does include Line (that is, it is correctly reachable from the remote service instance)? If not, the GWT-RPC generator (run when the compiler is invoked) might not have seen a clear path to how this type could be used. Common reasons for that include declaring a field as being of type Object, which in your head means that any type could be assigned, but GWT-RPC doesn't want to mark every possibly class as potentially serializable (both for security reasons and to avoid generating serialization code for your client for every possible type).   On Thursday, December 19, 2024 at 1:08:53 AM UTC-6 ma...@craig-mitchell.com wrote:

Neil Aggarwal <ne...@propfinancing.com>: Dec 19 10:11AM -0600 > Enumeration constants are serialized as a name only; none of the field values are serialized.       What are the consequences of not having the values?   Reading on the Internet, it means I can’t use valueOf() and ordinal().   But, does it work normally otherwise?   Can I assign a constant value to a field, read that value, and compare the value to one of the constants?       > Can you confirm that the policy file does include Line       It does not have Line in it:       @FinalFields, true   *com*._3dmathpuzzles.play.client.GetPuzzleService, false, false, false, false, _, 4203465842   *com*._3dmathpuzzles.slitherlink.RectangularWithDiagonalsPuzzle, true, true, false, false, *com*._3dmathpuzzles.slitherlink.RectangularWithDiagonalsPuzzle/2547295082, 2547295082   com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException, true, true, true, true, com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException/3936916533, 3936916533   com.google.gwt.user.client.rpc.RpcTokenException, true, true, false, false, com.google.gwt.user.client.rpc.RpcTokenException/2345075298, 2345075298   com.google.gwt.user.client.rpc.XsrfToken, false, false, true, true, com.google.gwt.user.client.rpc.XsrfToken/4254043109, 4254043109   com.propfinancing.puzzle.Puzzle, true, false, false, false, com.propfinancing.puzzle.Puzzle/1723715424, 1723715424   com.propfinancing.puzzle.slitherlink.Box, true, true, false, false, com.propfinancing.puzzle.slitherlink.Box/1302152982, 1302152982   com.propfinancing.puzzle.slitherlink.Box$STATE, true, true, false, false, com.propfinancing.puzzle.slitherlink.Box$STATE/1639054469, 1639054469   com.propfinancing.puzzle.slitherlink.BoxWithDiagonals, true, true, false, false, com.propfinancing.puzzle.slitherlink.BoxWithDiagonals/2774485663, 2774485663   com.propfinancing.puzzle.slitherlink.Component, true, false, false, false, com.propfinancing.puzzle.slitherlink.Component/4011233562, 4011233562   com.propfinancing.puzzle.slitherlink.Line$STATUS, true, true, false, false, com.propfinancing.puzzle.slitherlink.Line$STATUS/1640439993, 1640439993   com.propfinancing.puzzle.slitherlink.NumberedBox, true, true, false, false, com.propfinancing.puzzle.slitherlink.NumberedBox/1782628205, 1782628205   com.propfinancing.puzzle.slitherlink.Puzzle, true, false, false, false, com.propfinancing.puzzle.slitherlink.Puzzle/2584703185, 2584703185   com.propfinancing.puzzle.slitherlink.RectangularPuzzle, true, false, false, false, com.propfinancing.puzzle.slitherlink.RectangularPuzzle/3177548746, 3177548746   com.propfinancing.puzzle.slitherlink.RectangularWithDiagonalsPuzzle, true, false, false, false, com.propfinancing.puzzle.slitherlink.RectangularWithDiagonalsPuzzle/3793384887, 3793384887   java.lang.Exception, true, false, true, false, java.lang.Exception/1920171873, 1920171873   java.lang.RuntimeException, true, false, true, false, java.lang.RuntimeException/515124647, 515124647   java.lang.String, true, true, true, true, java.lang.String/2004016611, 2004016611   java.lang.Throwable, true, false, true, false, java.lang.Throwable/2953622131, 2953622131   java.util.ArrayList, true, true, false, false, java.util.ArrayList/4159755760, 4159755760   java.util.HashMap, true, true, false, false, java.util.HashMap/1797211028, 1797211028   java.util.LinkedHashMap, true, true, false, false, java.util.LinkedHashMap/3008245022, 3008245022       > the GWT-RPC generator (run when the compiler is invoked) might not have seen a clear path to how this type could be used       Unfortunately, it is silent about the reason.   I am hoping we can improve it help the developer instead of leaving me to make guesses.       Thank you,   Neil       --   Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com   We offer 30 year loans on single family houses!

Back to top

Digest for google-we...@googlegroups.com - 18 updates in 5 topics

Leon <leon.p...@gmail.com>: Dec 19 07:50AM +0100 Hi Neil,   If you hardcode an url in your GWT calls, it will be tied to that specific url. Local testing will not be possible (outside of hacking your own hosts file) and if you modify your servername you'll need to update your source code.   The webserver is the perfect place to forward your request to the tomcat instance. For apache webserver you can do this with the mod_proxy module. Nginx has the same with proxy_forward (or something similar, don't know by heart).   rg,   Leon.

Vassilis Virvilis <vas...@gmail.com>: Dec 19 09:15AM +0200 I agree with Leon and I can only add that there is also libapache2-mod-jk to directly proxy from apache to tomcat. The elevator's pitch is about speed but I think that is also simpler to understand and setup.     -- Vassilis Virvilis

Back to top

Getting 500 error from RPC call

Neil Aggarwal <ne...@propfinancing.com>: Dec 18 03:48PM -0600 I wrote a very simple class:       *package* com._3dmathpuzzles.slitherlink;       *import* java.io.Serializable;       *public* *class* TestPuzzle *implements* Serializable {   *private* *static* *final* *long* *serialVersionUID* = 1L;       /** Constructor */   *public* TestPuzzle() {   *super*();   }   }       And updated my RPC call to use it and I still get this:       Exception while dispatching incoming RPC call   com.google.gwt.user.client.rpc.SerializationException:   Type 'com._3dmathpuzzles.slitherlink.TestPuzzle' was not assignable to   'com.google.gwt.user.client.rpc.IsSerializable' and did not have a custom field serializer.   For security purposes, this type will not be serialized.: instance =   com._3dmathpuzzles.slitherlink.TestPuzzle@40a58058       I am not sure what to do about this. My class implements Serializable and has a no-arg constructor.       Thank you,   Neil       --   Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com   We offer 30 year loans on single family houses!

Colin Alworth <co...@colinalworth.com>: Dec 18 01:57PM -0800 You're triggering the LegacySerializationPolicy... we should make that clearer when it happens.   This occurs when your <hash>.gwt.rpc policy file wasn't present on the server (or wasnt at the expected path). Legacy serialization is much more strict in what it will accept.   Generated policy files ensure that the server and client agree on what can be serialized. This file is generated into the same directory as your .nocache.js file, and should be available on the server if running in production. If running with super dev mode and a separate server, you can direct the server to download the current policy file from SDM by specifying system property gwt.codeserver.port with the localhost port to the SDM server. Be sure to reload the server application or hot reload classes if they change, so that the server side classes match the client (and the client's policy file).   On Wednesday, December 18, 2024 at 3:48:49 PM UTC-6 ne...@propfinancing.com wrote:

Neil Aggarwal <ne...@propfinancing.com>: Dec 18 04:44PM -0600 > This occurs when your <hash>.gwt.rpc policy file wasn't present on the > server (or wasnt at the expected path). Legacy serialization is much more > strict in what it will accept.   I saw a warning about that in the log but not know what it meant. I am serving the client side files from Apache and the server side files from Tomcat so they are separate.   Where does the server side code expect the .gwt.rpc file to be?

Colin Alworth <co...@colinalworth.com>: Dec 18 06:11PM -0800 The server expects the client to tell it where the file should be, and the client reports that the file should be in the same directory as its .nocache.js file - we call that the "base directory" of a gwt application.   RemoteServiceServlet.getSerializationPolicy is responsible for looking this up, based on the incoming request, and the expected name of the generated file (according to the client). If using SDM and a port provided as I mentioned, this method will defer to getCodeServerPolicyUrl() if no policy file was found on the server itself. Otherwise, you'll see the warning you mentioned. On Wednesday, December 18, 2024 at 4:45:23 PM UTC-6 ne...@propfinancing.com wrote:

Neil Aggarwal <ne...@propfinancing.com>: Dec 18 10:06PM -0600 I see this in the log:       com._3dmathpuzzles.play.server.GetPuzzleServiceImpl: ERROR: The module path requested, /play/DiagonalSlitherlink/, is not in the same web application as this servlet, /3dmp. Your module may not be properly configured or your client and server code maybe out of date.       Looking at the source code for RemoteServiceServlet, I see that it wants the module path to start with the webapp context, but it does not match in my setup.       Is there a way to override the behavior, maybe load it manually or something?       I see a method putCachedSerializationPolicy but it is private.       Thank you,   Neil       --   Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com   We offer 30 year loans on single family houses!

Neil Aggarwal <ne...@propfinancing.com>: Dec 18 10:21PM -0600 > The server expects the client to tell it where the file should be, and the client reports that the file should   > be in the same directory as its .nocache.js file   > we call that the "base directory" of a gwt application.       I decided to stop fighting with GWT and moved the module from Apache to Tomcat. The test RPC started working once I did that.       I changed the code to try to retrieve my DiagonalSlitherlink puzzle, but it it is giving me an error. I am investigating.       Thanks for the help!       Neil       --   Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com   We offer 30 year loans on single family houses!

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to google-web-tool...@googlegroups.com.

[Neil Aggarwal]

> I think you are trying to learn GWT in the hardest way possible.

 

I am sure that is true, but I have never been one to shy away from

challenges.

 

As I see it, I can:

1. Continue trying to use my existing Java code with
   its intricate hierarchy and use of external libraries.
2. Don’t use my existing code.  Instead, write a parallel

set of code just for use with GWT.

 

According to the people on this list, #1 should work.  If it will work,

I prefer that solution to avoid having duplicated code (That’s one of

the reasons why I am using Java and GWT in the first place).  Of

course, “should” assumes a lot so nothing is guaranteed.

 

Using GwtIncompatible and super-source, I have been able
to get my code through the GWT compiler.  But now, the RPC

generator is giving me trouble.  I am not sure yet what is causing

that. 

 

As I see it, it could be one of:

1. Due to my lack of knowledge, my code is structured in a way

that violates some GWT requirement.

2. My code is stressing GWT and I hit some bug in the system.

 

I think it will be useful to know which.  If it is (a), then I will either
need to re-structure my code or stop the current effort and go to
solution #2 above.  If it is (b), fixing that makes GWT better.

 

I am still willing to continue this path if the people on this list
are still willing to help me.  So far, I have received amazing support
and would like to thank everyone for that.

[Craig Mitchell]

> make sure to clear the cache first

Sounds like you haven't setup your caching correctly.  Mine always works perfectly, never have to clear the cache in dev, or when doing a server update.  Here's my Filter:

/**
 * Tell the browser not to cache the .nocache files, by changing the expires time in the HTTP header.
 */
@Component
@Order(1)
public class ServletFilter implements Filter {
private static final String NO_CACHE = ".nocache.js";

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
String requestURI = ((HttpServletRequest)request).getRequestURI();

// Don't cache the nocache
if (requestURI.endsWith(NO_CACHE)) {
setNoCache((HttpServletResponse)response);
}

// Request HTTPS
((HttpServletResponse)response).setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains");

chain.doFilter(request, response);
}

private void setNoCache(HttpServletResponse httpResponse) {
long currentTime = new Date().getTime();
httpResponse.setDateHeader("Last-Modified", currentTime);
httpResponse.setDateHeader("Expires", currentTime - 86400000L);
httpResponse.setHeader("Pragma", "no-cache");
httpResponse.setHeader("Cache-Control", "no-store");
}
}

[Leon Pennings]

Hi Craig,

there are 101 hacks to try and keep the browser from caching. 

Problem is that it's a browser implementation on what to cache and what not, and how the browser determines what to cache when seems subject to change.

So for me I prefer to assume it doesn't work.

Having said that; except for the last-modified flag my config is the same as yours. I'll add it - thanks!

If it works, it works.

rg,

Leon.

Op vrijdag 20 december 2024 om 23:43:33 UTC+1 schreef Craig Mitchell:

[Thomas Broyer]

On Friday, January 3, 2025 at 6:51:34 AM UTC+1 leon.p...@gmail.com wrote:

Hi Craig,

there are 101 hacks to try and keep the browser from caching. 

Problem is that it's a browser implementation on what to cache and what not, and how the browser determines what to cache when seems subject to change.

So for me I prefer to assume it doesn't work.

That's not my experience.

Note that refreshing a page is different from navigating to it (through a link), or going back to it from the navigation history (might also use bfcache), particularly when it comes to subresources.

 

Having said that; except for the last-modified flag my config is the same as yours. I'll add it - thanks!

If it works, it works.

Fwiw,

• "Pragma: no-cache" never had a specified behavior in responses (it was initially created for requests)
• Cache-Control is widespread (released in all browsers 11 years ago: https://caniuse.com/mdn-http_headers_cache-control) so you can replace Expires with a max-age directive.
• I would also use no-cache over no-store: the content of the nocache files don't contain any user-sensitive information so it's ok to store them as long as you revalidate with the server that they're still up-to-date. For that, you need Last-Modified or ETag (preferred) response headers though (you can just use the file's modification date, or derive an ETag from its content). If your server doesn't send those, then I'd look for a better implementation (or work around it by implementing it myself in a filter as suggested here)
  See also https://jakearchibald.com/2016/caching-best-practices/ and https://web.dev/articles/http-cache#flowchart

[Craig Mitchell]

I'm too scared to change it without someone telling me it 100% works.  😆  When I swapped from GAE legacy to GAE standard, my filter got messed up, and people didn't get the updates correctly.  The amount of times I had to ask people to clear their cache was painful.

If we can agree on what the best filter should be, we should include it in https://github.com/NaluKit/gwt-maven-springboot-archetype  🙂

[Michael Conrad]

Have looked into to using the ?date hack to prevent caching?

You effectively append the system epoch time to the URL for the nocache JS file in the main HTML file.

--
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/19ac9860-4656-4237-81bb-fb3ab622d3a8n%40googlegroups.com.

&#8203;

[Colin Alworth]

Michael, that is not an effective solution to the bfcache "problem", since when the bfcache is used the page and none of its resources will be loaded - they are already loaded and active. From the perspective of the running page, it was hidden, and then shown again, but is still in memory and won't even hit your onModuleLoad when restored in this way. To effectively handle the case where the page is now out of date, listen for the pageshow event, compare the currently running state with the server, and use that to decide if you need to reload from scratch.

https://developer.mozilla.org/en-US/docs/Glossary/bfcache

https://developer.mozilla.org/en-US/docs/Web/API/Window/pageshow_event

If you're going to specify the date in the URL, you could just as easily inline the script's contents and avoid another call - even on h2 connections, that still costs a round-trip to the server and pauses page load while waiting for that ~2k document. With that said, I largely agree with "just set good headers on the server" for your *.nocache.* documents.

Take a little care with testing/validating etag though - stock Jetty at least does not hash the file to produce this (to avoid the expense of reading the entire file to produce the hash, then re-reading it from start to stream it), but uses the file modification date assuming is a valid proxy for changes. Thwarting this, gradle helpfully sets file metadata in a jar/war to a point decades in the past, regardless of actual values, to ensure its own caching isn't impacted by files being refreshed.

[Thomas Broyer]

On Monday, January 6, 2025 at 4:46:51 PM UTC+1 Colin Alworth wrote:

Take a little care with testing/validating etag though - stock Jetty at least does not hash the file to produce this (to avoid the expense of reading the entire file to produce the hash, then re-reading it from start to stream it), but uses the file modification date assuming is a valid proxy for changes.

Apache HTTPD (https://httpd.apache.org/docs/2.4/mod/core.html#fileetag) and Nginx (https://github.com/nginx/nginx/blob/e3a9b6ad08a86e799a3d77da3f2fc507d3c9699e/src/http/ngx_http_core_module.c#L1701-L1704) do something similar

 

Thwarting this, gradle helpfully sets file metadata in a jar/war to a point decades in the past, regardless of actual values, to ensure its own caching isn't impacted by files being refreshed.

Gradle doesn't do that by default, this is part of an explicit configuration to get reproducible builds: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.bundling.Jar.html#org.gradle.api.tasks.bundling.Jar:preserveFileTimestamps

You'd have the same issues with Bazel (does reproducible builds by default) or Maven (https://maven.apache.org/guides/mini/guide-reproducible-builds.html)

[Colin Alworth]

Thanks - I knew that Maven was explicitly opt-in, but several Gradle projects I've worked on have hit this issue so I assumed it was a facet of Gradle itself. Turns out instead, a single plugin shared among these projects, only referenced indirectly, was traversing the tasks of all projects and applying this. I guess you can draw an analogy to a maven parent pom doing configuration you didn't expect, except any plugin with access to the Project instance could technically have done this.

I also excluded Bazel, as the few developers who use it beyond trivial examples already will need to deeply understand its internals, and so would already expect this.