org.glassfish.jersey.containers:jersey-container-jetty-http:3.0.0 Unusable on JDK11+ #4655
Comments
|
The goal was to create a multirelease artifact that works for JDK 8 (well Jetty needs JDK 11, so that version just informs that JDK 11 is required) as well as for JDK 11. It looks like JDK 11 classes were not included during the build :( |
|
@birdflyer-lszo the release process of jakartified Jersey includes compilation of modules by different JDKs. Since several modules do not support JDKs prior to 11 we shall provide some stubs for JDK 1.8 which will inform user of in-availability of a particular module for used JDK. And that particular module shall support multi-release jar in order to provide expected functionality for supported JDKs. Jetty related modules where adjusted in that way, that is why you can see several profiles inside the pom.xml each of them is activated by different JDK. The order of release is: compile module using higher JDK to generate required functionality for supported JDK, then compile the same module using lower JDK to provide not-supported stub and pick up previously generated functionality from higher JDK. And then bundle all of this into the final JAR and release to central. I can admit that there was an error inside releasing job which did not properly generate functionality for 11+ JDKs and so only stubs where included into 3.0.0 release. Thus I can say that Jetty is not supported in that release due to that pity error. Profiles in POM files are however correct and there is no need to adjust them. The issue is already fixed and future releases of Jersey 3.x will be published properly. I will inform you (in this issue) when next release is available for public usage. And thank you for finding this out and reporting that. I apologise for that mistake which in fact had caused total unavailability of Jetty for the release of Jersey 3.0.0. |
|
Thanks for the update. And no worries, mistakes can happen :) |
|
Hello, I'm not sure if I'm correct to be posting in here, but today I went through the same struggles as the original poster (initially trying to follow the documentation which tells users to use the (indeed nowhere-to-be-found) JettyHttpContainerFactory class, so instead of using the Factory I went ahead and created a Jetty Server "by hand" and registered my jersey service using So I was able to run Jersey 3.0.0 on Jetty 11. However - and since I'm doing a modular (JPMS) project - I had to do a little bit of black magic to get the dependencies to behave (for one thing, jakarta.servlet is still a split package in the jetty / jersey combo context) but eventually got the server going. And finally, I came across a show-stopping serialization issue (for my project at least) at runtime which seems to relate to new reflection & access constraints in modular Java (see stacktrace below). So I was wondering a few things:
Thanks in advance! And here are my dependencies: |
|
It would be good if you can provide us a reproducer. However, a couple of googling shows a similar issue when a default method is used. Is |
|
@jansupol |
|
@birdflyer-lszo release 3.0.1 is published to Central, it includes fixes for Jetty connector and containers multirelease jars. So, this issue can be closed as resolved. @doriancransac if you believe the issue you are reporting is Jersey's bug please open a separate issue. |
|
hmm, I see the class now in the
|
|
All files which are bundled in META-INF/versions/11 shall be normally accessible when JDK 11+ is used. That is the purpose of multi release jar - it makes possible to provide different functionality for different JDKs in classes with same name. So, when you use JDK 1.8 only not supported exception will be thrown, when you use JDK 11 for the same import you shall be able to run container normally. |
|
alright, thanks for the info. guess then our build is screwed and somehow does not recognize MRJARs. i will look into this. |
|
Multi-release jar files are supported out of the box since JDK 9, so please check if you indeed run build using JDK 11+ (may be better 11.0.4+ due to some internal JDK errors fixed in and after 11.0.4). And for our inner tests those changes pass just fine, Jetty containers starts when JDK 11 is applied. And for JDK 1.8 Jetty does not work. |
|
Hello. We are still having the problem that @birdflyer-lszo had. With Java 11, and the classes in META-INF, we are not able to import the JettyHttpContainerFactory class. We are not using maven but gradle, so I don't know if that might be a problem for having different profiles or its just that something is stilling missing in 3.0.1 version....Thank you |
|
@RiceNeramy seems you are right, imported file shall be present in the main target as well. So, PR #4709 shall fix that, however this will be publicly available after the next release (3.0.2 may be). Meanwhile you can use the fix after it's merged from SNAPSHOT repository or build it for your needs separately. @birdflyer-lszo, this actually applies to you as well. Thanks for your patience :) |
|
@senivam Thank you very much for you quick response. Ok , good, we will use the fix then. Cheers! |
|
Any ETA on 3.0.2? I've been chasing my tail on this bug after updating dependencies for hours... before I realized that this was a multi-version jar issue. For me, it doesn't work properly in eclipse, when writing my test code, nor does it work properly when trying to use testng to run a jersey + jetty test case. Its going down the code path of telling me I'm on Java8..... |
|
Will the proposed fix in the referenced bug fix the fact that this class is missing from the jar file? Without this class, this bug needs to stay open.... |
|
For anyone else running across this issue, jakarta.ws.rs.ProcessingException: Jetty container is not supported on JDK version less than 11. I was able to work around it with 3.0.1 by "fixing" the jersey-container-jetty-http jar file, by pulling the JDK 11 classes out of the buried multi-jar location, and overwriting the JDK 8 classes in the normal places in the jar file. Without this fix, Eclipse is very confused about the state of this multi-jar file - I don't know multi-jar well enough to know what is wrong with it. The second required fix to make anything with maven / testng work is to provide the missing JettyTestContainerFactory.java - I just dropped a copy of it into my project locally. This whole multi-version jar mess seems like an awful lot of work / bugs just to tell someone that java 8 isn't supported... pretty sure developers would figure that out anyway... |
|
I'm not sure what the resolution was here, but the annoying issues with Eclipse not using the Can we please just delete the useless classes and replace them with the useful classes, so that people can actually use the Jetty container within Eclipse without resorting to patching the JAR in The other issue that I ran into is that repackaging Jersey and the Jetty container into my own uber-jar requires me to make my own JAR into a multi-release JAR, even though I am compiling at Java 17. Without setting |
|
@adriansuarez and which version of Jersey do you use? |
|
@senivam I'm running into this on 3.1.6, but I suspect any version that packages the Jetty container as a multi-jar would cause this. Basically what I'm experiencing is exactly what @darmbrust reported in 2021, but with the latest 3.x. I was able to workaround this by bumping the Jersey version to 4.0.0-M1, but I do not want to use a non-GA/milestone release. |
|
@adriansuarez the reason why we still keep multi-release jars is because there is a requirement to support a lover JDK than what is used to run Jetty 12. As you are saying, 4.0.0-M1 does not have it because it is already JDK 17 minimum. However the 3.1.x must support JDK 11, that is why multi-rlease jars are still in place. I'll take a look, why it does not work even with JDK 17. BTW, just for complete image, are you using JDK from OpenJDK, Oracle, Temurin, Azul or anything else? Thank you for reporting that. |
|
@senivam I added the following print statements: public static JettyHttpContainer createContainer(ResourceConfig config) {
var container = ContainerFactory.createContainer(JettyHttpContainer.class, config);
System.getProperties().forEach((k, v) -> System.err.println(k + "=" + v));
System.err.println(container.getClass().getCanonicalName());
System.err.println(container.getClass().getResource(""));
return container;
}Which display the following: It seems like the correct version of JettyHttpContainer is actually being used, but I am seeing bizarre runtime errors (the server just responds with "500 Server Error". I'll add more logging to see what the server is complaining about. I do not see these issues with 4.0.0-M1, and I also do not have these issues when running the repackaged uber-jar after adding @senivam To answer your question, Temurin-17.0.8+7. |
|
This is the stacktrace of the exception that generates the 500 response: |
|
@senivam Okay, I think I understand what the issue is. The I did find the class The solution was to explicitly add |
I am using the org.glassfish.jersey.containers:jersey-container-jetty-http:3.0.0 dependency to setup my Jetty container. While on version 2.x this worked just fine, version 3.0.0 does no longer seem to provide a JettyHttpContainerFactory class.
In the source repository there are multiple source directories for different JDKs, but the build does not seem to build one for JDK 11 onward. The JAR file published on https://repo1.maven.org/maven2/org/glassfish/jersey/containers/jersey-container-jetty-http/3.0.0/ appears to be the one for JDK8. According to the POM, JDK11+ modules are only built when a specific profile is active.
The repository does not seem to include a JDK11+ build of the jersey-container-jetty-http artifact. Is there a different repository that contains the JDK11 artifacts?
The text was updated successfully, but these errors were encountered: