-
Notifications
You must be signed in to change notification settings - Fork 382
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
base: main
Are you sure you want to change the base?
Conversation
…ed with GWT. Latest Jetty launcher with GWT and superdev mode fails without this when loading any classes related to JDBC access.
javax.sql should be loaded from the WEB-INF/lib. Also, I'm not sure how it's related to the linked issue. |
Hi Thomas,
This is to resolve the error one gets when using GWT and trying to connect
to a database on the backend:
[WARN] Server class 'javax.sql.DataSource' could not be found in the web
app, but was found on the system classpath
[ERROR] Found resouce but unrecognized URL format:
'jrt:/java.sql/javax/sql/DataSource.class'
Exception in thread "ContactQueueServicer" java.lang.NoClassDefFoundError:
javax/sql/DataSource
This occurs because the Jetty class loader cannot find jrt:DataSource class
because it can't handle the jrt prefix.
So the trick is to tell JettyLauncher to resolve the class javax.sql.* by
adding it to the allowed list as done in the pull request.
That shouldn't break anything. ???
For your suggestion, I don't know of a way to add a Java internal class as
a JAR to be able to place it in the WEB-INF/lib folder.
If you know of a way please share it.
Thank you,
Ian.
…On Mon, Dec 23, 2024 at 8:11 AM Thomas Broyer ***@***.***> wrote:
javax.sql should be loaded from the WEB-INF/lib. Also, I'm not sure how
it's related to the linked issue.
—
Reply to this email directly, view it on GitHub
<#10075 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMNVVOAATKHTZCGJSBGVTPT2HARYVAVCNFSM6AAAAABUDF43AGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJZHA3TMOJTHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
@ian-stiles Today we recommend to use So if you want to continue use |
@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) |
Hi Jens and Thomas,
Thank you for responding...
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?
For many, this is the only hurdle to having the awesome experience we've
gotten used to of being able to debug client and server-side from Eclipse
or IntelliJ.
Wouldn't that ease-of-use also help promote GWT as a going concern?
Remember, Java's tagline in the early days was "Write once, Run anywhere"
and GWT is the only thing helping that to stay true.
Thank you very much for the responses,
Ian.
…On Mon, Dec 23, 2024 at 12:04 PM Thomas Broyer ***@***.***> wrote:
@ian-stiles <https://github.com/ian-stiles> Ha ha, sorry, my Google fun
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)
—
Reply to this email directly, view it on GitHub
<#10075 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMNVVOEYCD2O2UR2DFZZMBD2HBNDZAVCNFSM6AAAAABUDF43AGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRQGE3TGNBVGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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
Currently the proposed plan is that GWT 2.13 will either change its default to See:
From my own experience I can tell you that using |
Ok, great. Thanks for the detailed answer.
I got the ServerContainerLauncher flavor working and am using that same
JettyLauncher guts that I posted.
Have a great holiday!
Ian.
…On Mon, Dec 23, 2024 at 4:50 PM Jens Nehlmeier ***@***.***> wrote:
@ian-stiles <https://github.com/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:
- #10057 <#10057>
- #9863 <#9863>
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
—
Reply to this email directly, view it on GitHub
<#10075 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMNVVOCPKF7DAGV5GXMB2SL2HCOS7AVCNFSM6AAAAABUDF43AGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRQGQ2DANRYGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Are we happy to close this and expect it to be part of #10056? |
Issue #9582
Latest Jetty launcher with GWT and superdev mode fails without this when loading any classes related to JDBC access.