Re: Building a GWT project in Eclipse 2019-03+ with Java 11.

[tekkyru]

Thanks to all who helped and inspired me, 

I've gotten rid of the Eclipse GWT plugin and have configured a Gradle 
project that uses Eclipse plugin, so it can be used standalone from command 
line or imported to Eclipse.

When imported to Eclipse it represents a webapp that can be added to a 
server of my choice configured in the Eclipse Servers tab. Also it includes 
the GWT CodeServer task that runs GWT Dev mode as separate process with 
separate classpath, avoiding Jar hell of the Eclipse GWT plugin, where 
dependencies of GWT-dev, GWT-user, Jetty and my app are mixed in the same 
JVM classpath.

I hope finally to find a time to strip the project down to essentials and 
publish it to the Github.

On Monday, February 21, 2022 at 9:07:19 PM UTC+1 tekkyru wrote:

> Sounds interesting, I'll definitely give it a try, thank you - and for the 
> gradle file, I really need a production grade gradle example 
>
> понедельник, 21 февраля 2022 г. в 11:27:04 UTC+1, Luis Fernando Planella 
> Gonzalez: 
>
>> > Our current workflow is using SuperDevMode + Jetty and I'd like to 
>> provide similar experience to our team.
>> I had a similar concern, as before we both SuperDevMode and the app in 
>> the same Java process.
>> After the switch, we need to start the codeserver and then the app, via 
>> Tomcat. But, things went well, because:
>>
>>1. You don't have to start your app in the build tool and connect 
>>remotely. The codeserver will write its files to the same place as the 
>>regular compilation would, and you can start your app in a debug session 
>> in 
>>Eclipse. We're using the built-in Tomcat server (with Eclipse WTP). Just 
>>make sure that after starting the codeserver, you have your workspace 
>>refreshed, so Eclipse can publish it accordingly (that's why we wrote the 
>>script, as mentioned in the previous post)
>>2. Starting the codeserver is actually slower than the app (at least 
>>for us, and the app is huge). When you debug the app, you'll eventually 
>> do 
>>an incompatible change that needs to restart the app. When using the 
>>codeserver as a separated process, it stays there, in the same place, 
>> even 
>>when you restart the app. IMO, this ended up being more productive than 
>> the 
>>previous setup
>>3. If GWT 3 is ever released, having a separated codeserver will be 
>>the only option
>>
>>
>> Em domingo, 20 de fevereiro de 2022 às 20:55:55 UTC-3, 
>> tequil...@gmail.com escreveu:
>>
>>> Thanks for the answer
>>>
>>> > Can't you somehow disable the module path or put all dependencies in 
>>> the classpath rather than the module path?
>>>
>>> Do you mean disabling java.xml module of JRE and depend on all xml stuff 
>>> explicitly? It means I'd have to rely on dependencies instead of stock 
>>> libraries (general app architecture choice) just to comply with a flawed 
>>> development tool needed only to run debug sessions. I'd prefer to avoid it 
>>> unless it's the only way.
>>>
>>> >  Alternatively, how about not using the Eclipse GWT Plugin?
>>>
>>> Our current workflow is using SuperDevMode + Jetty and I'd like to 
>>> provide similar experience to our team. 
>>> I saw such solutions (using gradle gretty plugin), so far decided 
>>> against it. As far as I understand running the code server and my webapp 
>>> via Gradle without Eclipse GWT plugin brings more hassle into everyday 
>>> development routine. This way the webapp must be launched not as Eclipse 
>>> debugging session but as Gradle task, and connected via remote debugging 
>>> session. I'd like to avoid it.
>>>
>>> воскресенье, 20 февраля 2022 г. в 12:33:18 UTC+1, t.br...@gmail.com: 
>>>
 On Saturday, February 19, 2022 at 1:57:16 AM UTC+1 tequil...@gmail.com 
 wrote:

> Hi Jasper
>
> I'll be just glad if my current progress saves someone's time.
> I progress on step by step basis, so far I succeeded in Eclipse build 
> and debugging.
>
> Most of my problems were caused by combination of JDK11+ (namely 
> modules) + Gradle + Eclipse + Eclipse GWT Plugin. 
>
> Reason: GWT SDK gwt-dev.jar contains lot of classes that must not be 
> visible to Eclipse compiler, but in fact they are, causing dreaded "The 
> package org.w3c.dom is accessible from more than one module: , 
> java.xml" error.
> When `gradle build` is issued in command line the gwt-dev.jar from the 
> maven repository is linked, it contains exactly essential google classes 
> and nothing more. Thus the build succeeds.
>
> But when you import such project in Eclipse under JDK11+ (I use JDK17) 
> and select a GWT SDK there're lots of build errors caused by "The package 
> is accessible from more than one module"
>

 Can't you somehow disable the module path or put all dependencies in 
 the classpath rather than the module path?

 

Re: CWE-749 GWT and eval()

[Colin Alworth]

David can you clarify how you are using eval, and what it is that makes you 
want to stop specifically? 

Using CSP is entirely opt-in (though likely a good idea), but there is 
nothing about GWT that is going to take away the ability to use eval.

On Tuesday, June 4, 2024 at 11:59:58 PM UTC-5 David wrote:

> I also use eval in my GWT application. What is an eval alternative in GWT?
>
>
> On Tuesday, June 4, 2024 at 10:12:12 PM UTC+8 Colin Alworth wrote:
>
>> Consider compiling your application with style=PRETTY or DETAILED so you 
>> can see more detail on the name of methods and the classes that surround 
>> the code you have questions about, it can make it easier to hunt these down.
>>
>> I pretty-printed the code snippet you shared, which results in this:
>> {
>> j = k.substring(Z, m);
>> l = k.substring(m + $)
>> } else {
>> j = k;
>> l = fb
>> }
>> c[j] = l
>> }
>> }
>> else if (j == xb) {
>> k = i.getAttribute(vb);
>> if (k) {
>> try {
>> d = eval(k)
>> } catch (a) {
>> alert(yb + k + zb)
>> }
>> }
>> } else if (j == Ab) {
>> k = i.getAttribute(vb);
>> if (k) {
>> try {
>> e = eval(k)
>> } catch (a) {
>> alert(yb + k + Bb)
>> }
>> }
>> }
>> }
>> }
>> __gwt_getMetaProperty = function(a) {
>> var b = c[a];
>> return b == null ? null : b
>> };
>>
>> The catch blocks have an alert in them, not something we typically see in 
>> GWT. It turns out this is part of the default linker, what looks like an 
>> old workaround to support extra meta tags contributing error handling code.
>>
>> https://github.com/gwtproject/gwt/blob/6cf9146a8c53743c99e48b1d1db42a2e2010e1d7/dev/core/src/com/google/gwt/core/ext/linker/impl/processMetas.js
>>   if (eq >= 0) {
>> name = content.substring(0, eq);
>> value = content.substring(eq + 1);
>>   } else {
>> name = content;
>> value = '';
>>   }
>>   metaProps[name] = value;
>> }
>>   } else if (name == 'gwt:onPropertyErrorFn') {
>> content = meta.getAttribute('content');
>> if (content) {
>>   try {
>> propertyErrorFunc = eval(content);
>>   } catch (e) {
>> alert('Bad handler \"' + content +
>>   '\" for \"gwt:onPropertyErrorFn\"');
>>   }
>> }
>>   } else if (name == 'gwt:onLoadErrorFn') {
>> content = meta.getAttribute('content');
>> if (content) {
>>   try {
>> onLoadErrorFunc = eval(content);
>>   } catch (e) {
>> alert('Bad handler \"' + content + '\" for 
>> \"gwt:onLoadErrorFn\"');
>>   }
>> }
>>   }
>> }
>>   }
>>
>>
>>   // Set some of the variables in the main script
>>   __gwt_getMetaProperty = function(name) {
>> var value = metaProps[name];
>> return (value == null) ? null : value;
>>   }
>>
>> This is used by most of the built-in linkers - there is an alternative 
>> file, processMetasNull.js, which could be used to remove these entirely. To 
>> use that, extend your current linker (presumably CrossSiteIframeLinker) and 
>> override getJsProcessMetas to return 
>> "com/google/gwt/core/ext/linker/impl/processMetasNull.js".
>>
>> I've filed https://github.com/gwtproject/gwt/issues/9967 to explore 
>> phasing these out or making them easier to disable.
>>
>> On Tuesday, June 4, 2024 at 4:54:38 AM UTC-5 giacomo@gmail.com wrote:
>>
>>> When we run automated security scan against our GWT project, one of the 
>>> main vulnerability is related to the presence of eval() functions in 
>>> the .nocache.js file
>>>
>>> ...{j=k.substring(Z,m);l=k.substring(m+$)}else{j=k;l=fb}c[j]=l}}else 
>>> if(j==xb){k=i.getAttribute(vb);if(k){try{d=*eval(k)*}catch(a){alert(yb+k+zb)}}}else
>>>  
>>> if(j==Ab){k=i.getAttribute(vb);if(k){try{e=*eval(k)*}catch(a){alert(yb+k+Bb)}__gwt_getMetaProperty=function(a){var
>>>  
>>> b=c[a];return b==null?null:b};w=d;ipmweb.__errFn=e}...
>>>
>>> We added the CSP that blocks eval executions and the application runs 
>>> correctly, meaning that those eval() is not called at runtime.
>>>
>>> Is there a way to get rid of those eval() functions? Is there someone 
>>> who knows in which cases those eval() gets executed? 
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: GWT, Java 17, jakarta.servlet, Eclipse, GWT plugin

[Colin Alworth]

> Clearly the GWT plugin/installed Jetty are not Jakarta-ready.  I could 
try to update and rebuild the plugin to make it so (maybe), but I'm so 
overwhelmed with other chores that I can't afford having that turn into 
another rabbit hole.  It's easier/safer/wiser to go back to javax.
If you mean the dev mode app server, there is no plan to do that _in gwt 
itself_, but there is an extension point in GWT that would let you do it 
yourself. Someone else has been thinking about building a small ecosystem 
around this in the issue tracker, but I haven't seen any movement here - 
see the discussion at https://github.com/gwtproject/gwt/pull/9866. We could 
easily have a jetty-12 impl, letting you run either jakarta or javax 
servlets, or switch to other servlet containers, and control as much or as 
little of the setup as you want. 
If you mean a particular plugin that you use with GWT, there are so many 
possible plugins out there, we can't guess which one isn't working for you. 
*Most* should be able to let you run your own external server though, or 
specify your own server using the -server argument (and implement it 
yourself, as linked/discussed above).

> MEDIUM ASK: Can anyone point me to better documentation or a tutorial or 
a how-I-did-it-blog post on getting that set up?  Like I said, I can figure 
it out, I'm sure, but I'd rather do it the quick/easy/no-wasted-time way.
If using maven, check out the modular-webapp archetype for a very light 
example, at https://github.com/tbroyer/gwt-maven-archetypes/. If not, 
please give us more detail about what you are using (or intend to use).

> SMALL ASK: Could GWT rename its BuildException class to 
GwtBuildException, to better support the twilight world of leaving Java 8 
without entirely moving to modules?
GWT doesn't have a BuildException class - can you give the fully qualified 
class name of the type that is irritating you? I see that Ant has such a 
class, and Gradle too, might you be thinking of one of those?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/d7ea67c7-c0e6-47d8-bafa-bb27baea8af5n%40googlegroups.com.

Re: GWT, Java 17, jakarta.servlet, Eclipse, GWT plugin

[Bob Lacatena]

Thanks for all the replies.  None of them directly addressed my needs, but 
in combination they all provided enough understanding to help me make some 
decisions:

Clearly the GWT plugin/installed Jetty are not Jakarta-ready.  I could try 
to update and rebuild the plugin to make it so (maybe), but I'm so 
overwhelmed with other chores that I can't afford having that turn into 
another rabbit hole.  It's easier/safer/wiser to go back to javax.

That still does not solve my larger problem of getting the web app to 
run... but it seems that must be unrelated to which servlet-api I use, so 
again, goodbye Jakarta-servlet.

I think I recognized it myself, but the advice to move to away from the 
embedded Jetty seems unavoidable, as it is deprecated.  It's just so darn 
convenient.  I also have never found clear examples on how to set to that 
up, what the pitfalls may be, how it will work, etc.  I'm sure I can figure 
it out... it's just not something I want to diverge into doing (but it 
seems at this point I must). 

MEDIUM ASK: Can anyone point me to better documentation or a tutorial or a 
how-I-did-it-blog post on getting that set up?  Like I said, I can figure 
it out, I'm sure, but I'd rather do it the quick/easy/no-wasted-time way.

The suggestion of breaking GWT into separate projects has some merit, as 
part of my entire problem is that, as I said in my intro, I am dealing with 
a massive, monolithic project that tries to do everything alll in one 
package.  In general, it would be wise to refactor that into multiple 
projects (not only around GWT, but other things like the build process, 
report generation, image generation, the Swing desktop app, and other 
facets).  Sadly, everything is so intertwined, and there is so much code, 
that doing so will be a massive effort, and this is just one of many 
high-pressure/short-timeframe projects on my plate, so I'm going to need to 
find the best/least-effort path in refactoring to make things work (with a 
longer-term project of continually refactoring things out).

I may consider falling back to an earlier version of Java, maybe 11, but 
I'm unsure if that will help.

I may also be having the problem because to solve many of my dependency 
conflicts I created a module-info.java file for my project.  I don't 
actually need to treat it as a module, except that the side effects of 
using "requires" within the module-info file solve those conflicts, and I 
can't otherwise solve the problem that, for example, GWT and Ant both 
define a BuildException class (among other myriad name conflicts).  But 
again... that problem can be at least sometimes solved by breaking the code 
up where conflicts occur (which again is off the time to due 
time/effort/budget conflicts).  Moving all of the GWT code to one project, 
or to three (client/shared/server), and the build code (Ant tasks) to 
another, and other code to other places, could help... 

An alternate option might be to rewrite the entire build process to use 
Maven or Gradle (many other, newer, smaller projects here use Gradle), but 
again... that's a massive detour that I'll take if I must, but it seems 
possible that this upgrade effort will wind up getting shelved before I 
have time to do that.

SMALL ASK: Could GWT rename its BuildException class to GwtBuildException, 
to better support the twilight world of leaving Java 8 without entirely 
moving to modules?

Anyway, thanks for all the helpful input.  The main points of "don't use 
jakarta yet", "abandon embedded Jetty", and "refactor your disastrously 
monolithic kaiju into something realistic" all help.

That said... I'd still like to at least have a better understanding as to 
why I get "Error occurred during initialization of boot layer", 
"java.lang.module.FindException: Module gwt.user not found, required by 
com.x.myapp" when the GWT container is in the class path, as well as if 
I explicitly add the gwt-user.jar to the path in the Run Configuration or 
into WEB-INF/lib (like get-servlet.jar).


On Wednesday, June 12, 2024 at 5:54:58 AM UTC-4 Thomas Broyer wrote:

> On Wednesday, June 12, 2024 at 11:27:27 AM UTC+2 Jens wrote:
>
> Needless to say that I have split client, shared and server code into 
> their own projects. This is the recommeneded project layout these days
>
>
>  * checks notes *
> I've been advocating for it for more than 12 years now 
> , and had 
> been using it for nearly 2 years already at the time. Java 8 would be 
> released more than 2 years later.
>
> (and note that this is –in terms of filesystem layouts– mostly due to how 
> build tools like Maven and Gradle work, also IDEs if you want smooth 
> integrations –although I'm sure IntelliJ IDEA could adapt to many layouts–; 
> this can be entirely different with Ant or Make, and definitely is 
> different with tools like Bazel/Buck/Pants/etc. Anyway the crux is to 
> understand what you're doing, and why 

Re: GWT, Java 17, jakarta.servlet, Eclipse, GWT plugin

[Thomas Broyer]

On Wednesday, June 12, 2024 at 11:27:27 AM UTC+2 Jens wrote:

Needless to say that I have split client, shared and server code into their 
own projects. This is the recommeneded project layout these days


 * checks notes *
I've been advocating for it for more than 12 years now 
, and had 
been using it for nearly 2 years already at the time. Java 8 would be 
released more than 2 years later.

(and note that this is –in terms of filesystem layouts– mostly due to how 
build tools like Maven and Gradle work, also IDEs if you want smooth 
integrations –although I'm sure IntelliJ IDEA could adapt to many layouts–; 
this can be entirely different with Ant or Make, and definitely is 
different with tools like Bazel/Buck/Pants/etc. Anyway the crux is to 
understand what you're doing, and why you're doing it, which means 
understanding how things work: classpaths, build classpaths, GWT Compiler, 
GWT DevMode/CodeServer, build tools, IDEs, etc.)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/13eff591-4443-45db-a0ba-470c8917cfccn%40googlegroups.com.

Re: GWT, Java 17, jakarta.servlet, Eclipse, GWT plugin

[Jens]

1. You do not have to use Jakarta if you want to migrate to Java 17. You 
can very well stay on javax and first make the JDK transition work
2. GWT's embedded Jetty is always javax because it is version 9.4.xx. The 
use of GWT's embedded Jetty is officially deprecated and you should use 
your own Jetty installation (local, docker image, maven/gradle plugin, 
...). This is especially true if you want to use Jakarta.
3. GWT 2.11 publishes *-jakarta dependencies that you can use once you 
start moving to Jakarta.
4. GWT Compiler only supports source level 11 so far

I use Java 11 for GWT client side code and Java 21 + javax for server side 
code. Needless to say that I have split client, shared and server code into 
their own projects. This is the recommeneded project layout these days 
because it gives you dedicated classpaths for each project and the option 
to use different JDK versions.

-- J.

Bob Lacatena schrieb am Mittwoch, 12. Juni 2024 um 00:01:47 UTC+2:

> I am wrestling with a massive effort that has been one stumbling block 
> after another. The core task is to convert a sadly monolithic and archaic 
> app from Java 8 to Java 17.
>
> My current subtask (maybe necessary, maybe not) is to convert everything 
> to use jakarta.servlet rather than javax.servlet, but when I try to declare 
> an import of com.google.gwt.user.server.rpc.jakarta.RemoteServiceServlet, 
> Eclipse just keeps replacing it with the "original" (non-jakarta) path.
>
> I was hoping I could solve this by renaming the gwt-servlet-jakarta.jar 
> file as gwt-servlet.jar, and putting that in war/WEB-INF/lib, but it 
> doesn't change the Eclipse behavior, AND it originally generated an error 
> that the size of that jar did not match the SDK... but after a clean-build 
> that problem (at least) went away.
>
> But my underlying problem is that I have classes that need to extend the 
> RemoteServiceServlet, and access the associated ServletContext, 
> HttpServletRequest, SerializationException and other classes that must all 
> be the jakarta (not javax) versions. 
>
> I can go back to using javax (and I'm not at all certain that the Eclipse 
> embedded Jatty server will use jakarta instead of javax, so maybe jakarta 
> won't work locally anyway)... but then I have to solve a problem where GWT 
> dev mode (with javax) gives me:
>
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Module gwt.user not found, required by 
> com.x.myapp
>
> Or do I have to move into a world where I stop using the so-convenient 
> embedded Jetty and deploy to and run an external server?
>
> Any advice on what to do (or, preferably, a deeper understanding of what 
> is happening) would be greatly appreciated.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/d97a9520-dab4-4bcd-b63b-e9b86ac0b930n%40googlegroups.com.

Re: GWT, Java 17, jakarta.servlet, Eclipse, GWT plugin

['tim_mac...@yahoo.co.uk' via GWT Users]

This might help: its a different solution to the issue Craig dealt with.
Its an extension of the gwt multi-module sample with an embedded Jetty,
for Java 11 without Spring.
https://github.com/timmacp/AppEngineGwt/tree/main

On Wednesday, June 12, 2024 at 9:03:01 AM UTC+1 Wejden Mrabti wrote:

> hello!
> @Craig it looks great what you have done!
> @bob I am working on same migration acutally, It looks that the embedded 
> Jetty in GWT DevMode has been deprecated in GWT 2.11 due to classloader 
> issues and other complexities. To avoid these problems, you can try  
> transition to a dedicated servlet container like Jetty or Tomcat for both 
> development and production. You can deploy your war file using Docker or a 
> Maven plugin. Ensure that your development environment is set up to deploy 
> to this dedicated servlet container instead of using the embedded Jetty. 
> You can check the updated GWT Getting Started Guide  (
> https://www.gwtproject.org/gettingstarted-v2.html )for detailed 
> instructions on setting up your project and development environment, making 
> the transition from Java 8 to Java 17 smoother.
>
> Le mercredi 12 juin 2024 à 02:27:57 UTC+2, Craig Mitchell a écrit :
>
>> I would recommend creating a new project with everything that you want to 
>> use, get it working how you like, then use that as a template on how you 
>> will upgrade your existing project.
>>
>> For my project that I needed to upgrade from Java 8 to Java 17 (because 
>> Google App Engine dropped support for Java 8).  I decided I would go 
>> "all-in" and get it onto the latest of everything.  So I needed to switch 
>> to use Maven, switch to use a client/server/shared structure, switch to use 
>> my own server (I went with Undertow), and switch to use Jakarta.  I also 
>> decided to go with Spring Boot (as Google App Engine had examples for 
>> that), so I used 
>> https://github.com/NaluKit/gwt-maven-springboot-archetype to create a 
>> sample project, and used that as a guide on how to upgrade my existing 
>> project.  Oh, and I also switched from Eclipse to IntelliJ.
>>
>> It was a big job and a lot of work, but now everything is running 
>> beautifully, so worth it in the long run.
>>
>> On Wednesday 12 June 2024 at 8:01:47 am UTC+10 Bob Lacatena wrote:
>>
>>> I am wrestling with a massive effort that has been one stumbling block 
>>> after another. The core task is to convert a sadly monolithic and archaic 
>>> app from Java 8 to Java 17.
>>>
>>> My current subtask (maybe necessary, maybe not) is to convert everything 
>>> to use jakarta.servlet rather than javax.servlet, but when I try to declare 
>>> an import of com.google.gwt.user.server.rpc.jakarta.RemoteServiceServlet, 
>>> Eclipse just keeps replacing it with the "original" (non-jakarta) path.
>>>
>>> I was hoping I could solve this by renaming the gwt-servlet-jakarta.jar 
>>> file as gwt-servlet.jar, and putting that in war/WEB-INF/lib, but it 
>>> doesn't change the Eclipse behavior, AND it originally generated an error 
>>> that the size of that jar did not match the SDK... but after a clean-build 
>>> that problem (at least) went away.
>>>
>>> But my underlying problem is that I have classes that need to extend the 
>>> RemoteServiceServlet, and access the associated ServletContext, 
>>> HttpServletRequest, SerializationException and other classes that must all 
>>> be the jakarta (not javax) versions. 
>>>
>>> I can go back to using javax (and I'm not at all certain that the 
>>> Eclipse embedded Jatty server will use jakarta instead of javax, so maybe 
>>> jakarta won't work locally anyway)... but then I have to solve a problem 
>>> where GWT dev mode (with javax) gives me:
>>>
>>> Error occurred during initialization of boot layer
>>> java.lang.module.FindException: Module gwt.user not found, required by 
>>> com.x.myapp
>>>
>>> Or do I have to move into a world where I stop using the so-convenient 
>>> embedded Jetty and deploy to and run an external server?
>>>
>>> Any advice on what to do (or, preferably, a deeper understanding of what 
>>> is happening) would be greatly appreciated.
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/960a7bb5-7443-4e97-94e7-3c8b822f4afan%40googlegroups.com.

Re: GWT, Java 17, jakarta.servlet, Eclipse, GWT plugin

[Wejden Mrabti]

hello!
@Craig it looks great what you have done!
@bob I am working on same migration acutally, It looks that the embedded 
Jetty in GWT DevMode has been deprecated in GWT 2.11 due to classloader 
issues and other complexities. To avoid these problems, you can try  
transition to a dedicated servlet container like Jetty or Tomcat for both 
development and production. You can deploy your war file using Docker or a 
Maven plugin. Ensure that your development environment is set up to deploy 
to this dedicated servlet container instead of using the embedded Jetty. 
You can check the updated GWT Getting Started Guide  
(https://www.gwtproject.org/gettingstarted-v2.html )for detailed 
instructions on setting up your project and development environment, making 
the transition from Java 8 to Java 17 smoother.

Le mercredi 12 juin 2024 à 02:27:57 UTC+2, Craig Mitchell a écrit :

> I would recommend creating a new project with everything that you want to 
> use, get it working how you like, then use that as a template on how you 
> will upgrade your existing project.
>
> For my project that I needed to upgrade from Java 8 to Java 17 (because 
> Google App Engine dropped support for Java 8).  I decided I would go 
> "all-in" and get it onto the latest of everything.  So I needed to switch 
> to use Maven, switch to use a client/server/shared structure, switch to use 
> my own server (I went with Undertow), and switch to use Jakarta.  I also 
> decided to go with Spring Boot (as Google App Engine had examples for 
> that), so I used https://github.com/NaluKit/gwt-maven-springboot-archetype 
> to create a sample project, and used that as a guide on how to upgrade my 
> existing project.  Oh, and I also switched from Eclipse to IntelliJ.
>
> It was a big job and a lot of work, but now everything is running 
> beautifully, so worth it in the long run.
>
> On Wednesday 12 June 2024 at 8:01:47 am UTC+10 Bob Lacatena wrote:
>
>> I am wrestling with a massive effort that has been one stumbling block 
>> after another. The core task is to convert a sadly monolithic and archaic 
>> app from Java 8 to Java 17.
>>
>> My current subtask (maybe necessary, maybe not) is to convert everything 
>> to use jakarta.servlet rather than javax.servlet, but when I try to declare 
>> an import of com.google.gwt.user.server.rpc.jakarta.RemoteServiceServlet, 
>> Eclipse just keeps replacing it with the "original" (non-jakarta) path.
>>
>> I was hoping I could solve this by renaming the gwt-servlet-jakarta.jar 
>> file as gwt-servlet.jar, and putting that in war/WEB-INF/lib, but it 
>> doesn't change the Eclipse behavior, AND it originally generated an error 
>> that the size of that jar did not match the SDK... but after a clean-build 
>> that problem (at least) went away.
>>
>> But my underlying problem is that I have classes that need to extend the 
>> RemoteServiceServlet, and access the associated ServletContext, 
>> HttpServletRequest, SerializationException and other classes that must all 
>> be the jakarta (not javax) versions. 
>>
>> I can go back to using javax (and I'm not at all certain that the Eclipse 
>> embedded Jatty server will use jakarta instead of javax, so maybe jakarta 
>> won't work locally anyway)... but then I have to solve a problem where GWT 
>> dev mode (with javax) gives me:
>>
>> Error occurred during initialization of boot layer
>> java.lang.module.FindException: Module gwt.user not found, required by 
>> com.x.myapp
>>
>> Or do I have to move into a world where I stop using the so-convenient 
>> embedded Jetty and deploy to and run an external server?
>>
>> Any advice on what to do (or, preferably, a deeper understanding of what 
>> is happening) would be greatly appreciated.
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/fce719ed-dadf-42b2-97eb-a42599370bfen%40googlegroups.com.