-
Notifications
You must be signed in to change notification settings - Fork 356
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
2.x/examples/osgi-helloworld-webapp does not work with Jetty 12 but with Jetty 10 #5522
Comments
Jetty 12 is aligned with Jakarta EE 10, whereas Jetty 9 is aligned with Jakarta EE 8. |
IMPORTANT: You need to add this to MANIFEST
|
@jansupol We wrote a comment at the same time :-) I'm using Jetty 12 with EE8 |
@gpfeifer Can you point us to a documentation regarding this MANIFEST tag? |
There is no documentation as far as I know. As I wrote in jetty/jetty.project#11315 it took me some hours to find out that this entry is needed. I found this entry in: https://github.com/jetty/jetty.project/tree/jetty-12.0.x/jetty-ee8/jetty-ee8-osgi |
I created a PR (#5524). The PR contains a minimalistic example of a working osgi-helloworld-jetty-12-webapp. Unfortunately a automated JUnit test is missing. |
This is the chart you need ...
Note: Jetty 12 server has no servlet dependencies anymore. |
Using your definitions of Jersey versions to EE levels, the extended chart would look like ...
But that doesn't make sense, as we know you support Jetty 9. Looking at your codebase.
Ah, Jersey 2.x codebase doesn't support EE8, it supports EE7 (based on it's use of Servlet 2.4/2.5), that's the mistake!
|
Technically speaking, Jersey 2.x supports Eclipse Jetty 7, as that's the version that introduced support for Servlet 2.4 (Jetty 8 was Servlet 3.0) |
@joakime The codebase I'm working on is running in production and is using Jetty 10 and Jersey 2.x. I'm migrating this codebase to Jetty 12. The Jersey example (2.x/examples/osgi-helloworld-webapp) works with Jetty 10 and Jersey 2.x. But is does not work with Jetty 12 ee8. My example (osgi-helloworld-webapp-jetty-12) works with Jetty 12 (ee8) and Jersey 2.x. I will use the approach used in osgi-helloworld-webapp-jetty-12 in my codebase. Is there anything against it? |
@joakime Or in other words: I don't get it. Jetty 10 works with Jersey 2.x in production. Jetty 12 e88 seems to work with Jetty 2.x, but I'm not finished with my migration. |
@gpfeifer some history ...
The fact that it seems to work for you is just luck, and is not to be relied on, as the most trivial change can suddenly cause issues for you. (eg: using Java 11 or older then moving to Java 17 and using those old versions of the Servlet spec, suddenly some of your responses are different.) In Jetty 12, ee8, we try to maintain bug for bug compatibility with how things worked back then, but it's not perfect, and only strives for the bugs that existed back in EE8 days, not earlier. |
Background
I'm trying to migrate some legacy code from Jetty 10 to Jetty 12.
I'm using Jetty 12 ee8 and Jersey 2.x.
Issue
https://github.com/eclipse-ee4j/jersey/tree/2.x/examples/osgi-helloworld-webapp does work with Jetty 10 but not with Jetty 12.
See jetty/jetty.project#11315
[2024-01-30 13:07:02] [WARNING] [org.eclipse.jetty.ee8.webapp.WebAppContext] Failed startup of context oeje8w.WebAppContext@65099eb1{/helloworld,/helloworld,file:///tmp/jetty-0_0_0_0-8080-bundleFile-_helloworld-any-3729372861759542448/webapp/,false}{file:/home/gpf/cix/git/vpms-server/vsrv-deliver/server/vpms-server-data/org.eclipse.osgi/98/0/bundleFile}
[2024-01-30 13:07:02] [INFO ] [org.eclipse.jetty.server.handler.ContextHandler] Started oeje8n.ContextHandler$CoreContextHandler@13f204a3{/helloworld,/helloworld,b=file:///tmp/jetty-0_0_0_0-8080-bundleFile-_helloworld-any-3729372861759542448/webapp/,a=UNAVAILABLE,h=oeje8n.ContextHandler$CoreContextHandler$CoreToNestedHandler@705b8920{STARTED}}
Jersey throws a ResourceFinderException with this message:
org.glassfish.jersey.server.internal.scanning.ResourceFinderException: The URI scheme bundleentry of the URI bundleentry://[...] not supported. Package scanning deployment is not supported for such URIs.
Try using a different deployment mechanism such as explicitly declaring root resource and provider classes using an extension of javax.ws.rs.core.Application
The text was updated successfully, but these errors were encountered: