Google Web Toolkit

Wednesday, January 28, 2026

Re: domino-jackson

Doesn't seem like it's engineered for TeaVM, that wouldn't be easy I'm guessing, works great for GWT though. TeaVM can do deserializing natively but, somewhat labourious.

Yahoo Mail: Search, Organize, Conquer

On Tue, Jan 27, 2026 at 8:20 PM, Vegegoku
<akabme@gmail.com> wrote:

Rious
I can't really give a definitive answer without seeing how the serializer/deserializer is implemented, but my initial suspicion is related to field name transformations.

GWT performs quite a bit of renaming and optimization during compilation, and domino-jackson works by mapping the original property string to the renamed field. Since the compiler renames the field consistently everywhere it's used, the mapping still works.

TeaVM, however, might be doing something different—possibly renaming fields inconsistently between the POJO and the classes that reference it. I'm not familiar enough with TeaVM's internals to say for sure.

The fact that explicitly specifying the property name in the annotation solves the issue makes the behavior even more puzzling without seeing the relevant code.
On Tuesday, January 27, 2026 at 10:27:11 PM UTC+3 Tim Macpherson wrote:

Works great for me in GWT so far, trying it in TeaVM now, so not sure if this issue is in scope ?
TeaVM at the minimum does a bit of name changing and domino-jackson deserializer fails with my DTO. One suggestion is add basic Jackson annotations to every field in the DTO I think it's @JsonProperty, then domino-jackson will adapt the deserializer. Anyone know if that's correct ? Thanks

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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/51a1ad21-3ed6-44a7-8cd2-c9040af91266n%40googlegroups.com.

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/563739128.8465951.1769545780922%40mail.yahoo.com.

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/2023771908.9060927.1769616822290%40mail.yahoo.com.

Tuesday, January 27, 2026

I haven't tried adding basic domino @JsonProperty yet, just wondering if there's an obvious problem and that won't fix, I'll try it tomorrow, apparently domino-jackson respects it but let's see if it works tomorrow

Yahoo Mail: Search, Organize, Conquer

On Tue, Jan 27, 2026 at 8:20 PM, Vegegoku
<akabme@gmail.com> wrote:

I can't really give a definitive answer without seeing how the serializer/deserializer is implemented, but my initial suspicion is related to field name transformations.

GWT performs quite a bit of renaming and optimization during compilation, and domino-jackson works by mapping the original property string to the renamed field. Since the compiler renames the field consistently everywhere it's used, the mapping still works.

TeaVM, however, might be doing something different—possibly renaming fields inconsistently between the POJO and the classes that reference it. I'm not familiar enough with TeaVM's internals to say for sure.

The fact that explicitly specifying the property name in the annotation solves the issue makes the behavior even more puzzling without seeing the relevant code.
On Tuesday, January 27, 2026 at 10:27:11 PM UTC+3 Tim Macpherson wrote:

Works great for me in GWT so far, trying it in TeaVM now, so not sure if this issue is in scope ?
TeaVM at the minimum does a bit of name changing and domino-jackson deserializer fails with my DTO. One suggestion is add basic Jackson annotations to every field in the DTO I think it's @JsonProperty, then domino-jackson will adapt the deserializer. Anyone know if that's correct ? Thanks

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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/51a1ad21-3ed6-44a7-8cd2-c9040af91266n%40googlegroups.com.

Re: domino-jackson

I can't really give a definitive answer without seeing how the serializer/deserializer is implemented, but my initial suspicion is related to field name transformations.

GWT performs quite a bit of renaming and optimization during compilation, and domino-jackson works by mapping the original property string to the renamed field. Since the compiler renames the field consistently everywhere it's used, the mapping still works.

TeaVM, however, might be doing something different—possibly renaming fields inconsistently between the POJO and the classes that reference it. I'm not familiar enough with TeaVM's internals to say for sure.

The fact that explicitly specifying the property name in the annotation solves the issue makes the behavior even more puzzling without seeing the relevant code.

On Tuesday, January 27, 2026 at 10:27:11 PM UTC+3 Tim Macpherson wrote:

Works great for me in GWT so far, trying it in TeaVM now, so not sure if this issue is in scope ?
TeaVM at the minimum does a bit of name changing and domino-jackson deserializer fails with my DTO. One suggestion is add basic Jackson annotations to every field in the DTO I think it's @JsonProperty, then domino-jackson will adapt the deserializer. Anyone know if that's correct ? Thanks

Yahoo Mail: Search, Organize, Conquer

domino-jackson

Works great for me in GWT so far, trying it in TeaVM now, so not sure if this issue is in scope ?

TeaVM at the minimum does a bit of name changing and domino-jackson deserializer fails with my DTO. One suggestion is add basic Jackson annotations to every field in the DTO I think it's @JsonProperty, then domino-jackson will adapt the deserializer. Anyone know if that's correct ? Thanks

Yahoo Mail: Search, Organize, Conquer

Monday, January 26, 2026

Strict CSP (nonce + strict-dynamic) with GWT – CSP violation from code-splitting

Hi,

I'm working on a classic GWT application and trying to apply a strict Content Security Policy (CSP) using a nonce generated per request.

CSP Using:

default-src 'self'; script-src 'self' 'nonce-<dynamic>' 'strict-dynamic' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; object-src 'self'; img-src 'self' data:;

What's working:

The app loads and runs correctly.
GWT is able to load its scripts dynamically.
The iframe now uses a safe URL (about:blank) instead of a javascript: URL and works with the current CSP.
No functional issues in the app.

What's the problem:
Even though everything works, the browser console shows this error:

Running the JavaScript URL violates the Content Security Policy directive

The stack trace originates from GWT code-splitting (runAsync), specifically during execution of split fragments (e.g., application-0.js).
This appears to involve runtime JavaScript execution via javascript: URLs, which is blocked under strict CSP.

My questions:

Is there a supported way in GWT to avoid this javascript: execution when using code splitting?
Is this console error considered a known limitation of classic GWT under strict CSP, and acceptable if the application works correctly?

I'd like to keep CSP strict and avoid adding unsafe-inline.

Thanks!

Wednesday, January 14, 2026

Nalu 4.0.0 released

We added some new features:

* clean URL support
* url parameter support

For more informations please visit: https://github.com/NaluKit/nalu/releases/tag/4.0.0

Re: GWT and IntelliJ IDEA as a single, unified product

> I have seen a post that a maven plugin can be used to start the codeserver. Though I don't know anything about it and how to configure that in Intellij IDEA. There is this page: https://www.gwtproject.org/usingintellij.html Though, a quick attempt failed.

> Could not find goal 'codeserver' in plugin org.codehaus.mojo:gwt-maven-plugin:2.10.0 among available goals.

You'd need to switch from your current plugin https://www.mojohaus.org/ to this plugin https://tbroyer.github.io/gwt-maven-plugin/

Then it runs great with the maven launcher in IntelliJ: https://www.gwtproject.org/images/intellij-run-code-server.png

You can create a sample project to see how it fits together https://github.com/NaluKit/gwt-maven-springboot-archetype (this uses SpingBoot, but you can ignore that, just look and see how the GWT codeserver is configured).

On Thursday, 15 January 2026 at 1:52:44 am UTC+11 Oleg Ravun wrote:

And removing all options brings this error:
Could not find goal 'codeserver' in plugin org.codehaus.mojo:gwt-maven-plugin:2.10.0 among available goals.

On Wed, Jan 14, 2026 at 9:43 AM Oleg Ravun <ora...@gmail.com> wrote:
The Intellij IDEA GWT plugin does not work with Intellij IDEA versions above 2025.2.2. And it does not look like it is going to be fixed.
https://youtrack.jetbrains.com/issue/IDEA-380767/Problem-starting-GWT-configuration-after-latest-hotfix
https://youtrack.jetbrains.com/issue/IDEA-379830/Move-GWT-to-obsolete-plugins
We have the same setup with maven project that is synched with Intelllij IDEA though it seems like we need a new approach to start the codeserver. Or we are stuck with the old Intellij IDEA version.
I have seen a post that a maven plugin can be used to start the codeserver. Though I don't know anything about it and how to configure that in Intellij IDEA. There is this page: https://www.gwtproject.org/usingintellij.html
Though, a quick attempt failed.
Specifying maven artifact ID after -pl says, "[ERROR] Could not find the selected project in the reactor".
And where would go all other options that I have on Intellij IDEA GWT plugin Dev Mode parameters "-noserver -port 8080 -sourceLevel 11 -war"?

On Wed, Jan 14, 2026 at 5:16 AM Frank <frank....@gmail.com> wrote:
I have Utlimate and we use the GWT plugin for all our projects.
Also to run the projects from within IntelliJ
In my opinion it works perfectly (auto synced with maven).

Op donderdag 1 januari 2026 om 23:35:28 UTC+1 schreef Craig Mitchell:
> or lets say made it free for now

To be clear, while you can now install it, unless you have Ultimate, you can't use it.

On Friday, 2 January 2026 at 3:06:44 am UTC+11 Vegegoku wrote:
I have Intellij ultimate but I dont use it, I just use the new maven plugin with SDM, debugging in the browser with source maps. maven and the command line all I personally need, It might have its uses when it comes to UiBinder and some checks, but I guess those still need the plugin to be updated first, good news is that you now can see the official plugin in intellij is because JetBrains open sourced it(https://plugins.jetbrains.com/plugin/14590-gwt) or lets say made it free for now, the source code didnt go public yet but when that happens there is a good chance someone will pick it up and update it.

On Tuesday, December 30, 2025 at 7:42:09 AM UTC+3 Craig Mitchell wrote:
Previously, I was using the free IntelliJ Community Edition. However, now IntelliJ IDEA is a single, unified product (with an upgrade option to Ultimate).

Before, with the Community Edition, there was no GWT plugin available. Now I see these:

I also see JavaScript debugger plugins that never showed up before.

Do people use these? Any other plugins recommended for GWT?

--
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/cb7f5c5d-92a2-4e07-84f2-a54bff7bc918n%40googlegroups.com.