Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JettyLauncher to allow all javax.sql.* classes to be loaded, Issue #9582 #10075

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ian-stiles
Copy link

@ian-stiles ian-stiles commented Dec 23, 2024

Issue #9582

Latest Jetty launcher with GWT and superdev mode fails without this when loading any classes related to JDBC access.

…ed with GWT.

Latest Jetty launcher with GWT and superdev mode fails without this when loading any classes related to JDBC access.
@tbroyer
Copy link
Member

tbroyer commented Dec 23, 2024

javax.sql should be loaded from the WEB-INF/lib. Also, I'm not sure how it's related to the linked issue.

@ian-stiles
Copy link
Author

ian-stiles commented Dec 23, 2024 via email

@jnehlmeier
Copy link
Member

@ian-stiles JettyLauncher is deprecated since GWT 2.11 and will eventually be removed in the future (see release notes of 2.11). This has been done because GWT DevMode still uses Jetty 9.4.44, JettyLauncher contains classloader hacks we do not want to maintain anymore and lastly because developers use the provided Jetty of DevMode as general purpose application server and regularly ask to update the version or make something work that JettyLauncher does not cover.

Today we recommend to use DevMode -noserver or CodeServer (DevMode -noserver is basically the same as CodeServer mapping DevMode arguments to CodeServer arguments) and bring your own application server that you can configure as you like. The benefit is that it can be up-to-date and closely mimic your production server without any GWT specific classloader hacks.
Alternatively you can implement your own ServletContainerLauncher to start an application server of your choice via DevMode. You can then use your own version of ServletContainerLauncher using DevMode -server com.example.MyCustomServletContainerLauncher.

So if you want to continue use DevMode to start your Jetty application server you should create your own little project, copying JettyLauncher and its dependencies to have a starting point and then adjust it as needed.

@tbroyer
Copy link
Member

tbroyer commented Dec 23, 2024

@ian-stiles Ha ha, sorry, my Google fu failed me on mobile (and I so never/rarely directly use jdbc classes I forgot they came with the jdk)

That said, this is more a workaround than a fix, so I agree with Jens that you'd better create your own "launcher" removing all the classloader trickery that JettyLauncher inherited from legacy (or use a separate server)

@ian-stiles
Copy link
Author

ian-stiles commented Dec 23, 2024 via email

@jnehlmeier
Copy link
Member

@ian-stiles

Wouldn't it help a large number of people hitting this issue if you just
added javax.sql to the allowed list since JettyLauncher is deprecated?

No, because it would mean that these people are then stuck on an old (unsupported) version of GWT once the new version does not ship JettyLauncher anymore and these people are then in the same situation as you now if they want to upgrade GWT: They have to provide their own implementation.

In addition to what I said before a larger reason is also the shift of javax.servlet to jakarta.servlet. While GWT 2.12 has an automatically generated gwt-servlet-jakarta.jar for server side classes provided by GWT, it is not so easy for DevMode. Jetty 12 might be an option but it requires Java 17 and GWT is just switching from 8 to 11. At the end it will be better to externalize the application server component of DevMode and let people choose which implementation they want to use, including their own.

Starting with GWT 2.11 the SDK ships two implementations of ServletContainerLauncher:

  • JettyLauncher (javax.servlet based, deprecated)
  • StaticResourceServer (new, can only serve static files)

Currently the proposed plan is that GWT 2.13 will either change its default to StaticResourceServer or force the developer to select an implementation when launching DevMode. GWT 2.13 and likely 2.14 will still ship JettyLauncher but you have to manually select it. After that JettyLauncher will likely be removed from the SDK.

See:

From my own experience I can tell you that using CodeServer directly (instead of DevMode) and having a way to launch your own servlet container (local jetty installation, official or custom made jetty docker image) to deploy your *.war file to isn't too much of a burden. Once you have figured out a setup that fits your project you never have to think about server issues caused by GWT again.
I think many people have migrated to Maven and use the gwt-maven-plugin along with a multi-module project, otherwise your linked issue that this PR wants to fix would have way more comments.
That is why GWTs "Getting started" guide now also uses Maven: https://www.gwtproject.org/gettingstarted-v2.html

@ian-stiles
Copy link
Author

ian-stiles commented Dec 24, 2024 via email

@niloc132
Copy link
Member

niloc132 commented Jan 8, 2025

Are we happy to close this and expect it to be part of #10056?

@eliasbalasis
Copy link

Are we happy to close this and expect it to be part of #10056?

I believe we can close this, modifying JettyLauncher is a suitable workaround.
I also intend to give #10056 a try, depending on priorities and workload.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants