netbeans
netbeans copied to clipboard
New Jersey 3 module
~~I have upgraded Jersey from 2.35 to 3.1.3. Related dependencies were upgraded and references to javax were switched to jakarta as well.~~
I have created a new module for Jersey 3 so that both Jersey 2 and 3 can co-exist.
This will brake Java EE/Jakarta EE 8 and prior projects, maybe add another Library called Jersey 3.x.y?
I haven't checked for what this is used for internally, but if its just a lib wrapper for ant projects (I have the suspicion it is more than that), i would update it to the latest javax release and leave it there. https://projects.eclipse.org/projects/ee4j.jersey/releases/2.40
This will brake Java EE/Jakarta EE 8 and prior projects, maybe add another Library called Jersey 3.x.y?
Can we ship two Jersey versions without having conflicts?
At some point we will have to upgrade to Jersey 3. Not sure if it's the right moment to do so. As a side note, I think that the Jersey version shipped by websvc.restlib breaks the REST Client plugin. See #6566.
You can have different versions of the same library, check the Ant Library, there are different versions for JSF and Spring:
I do not think it is as a matter of "upgrade" but of "support", we should support Jersey 2 for Java/Jakarta EE 8 and prior and add support for Jersey 3 for Jakarta EE 9 and onward.
I agree with @mbien, we should update it to the latest 2.x version.
Ok, my take on this is:
a) jersey is broken because it relies on autodetection of features and does not protect against classes it can't load b) relying on autodiscovery is nice, but broken if you don't control the whole classpath
For "REST Client" I think the solution is trivial (CommonProperties.FEATURE_AUTO_DISCOVERY_DISABLE disabled auto detection):
private void buildClient(boolean verifySslCertificates) {
ClientConfig config = new ClientConfig()
.connectorProvider(new ApacheConnectorProvider())
.property(ClientProperties.CONNECT_TIMEOUT, 20000)
.property(ClientProperties.FOLLOW_REDIRECTS, true)
.property(CommonProperties.FEATURE_AUTO_DISCOVERY_DISABLE, true)
.property(JsonGenerator.PRETTY_PRINTING, true)
.register(new LoggingFeature(logger, Level.INFO, LoggingFeature.Verbosity.HEADERS_ONLY, 8192));
client = verifySslCertificates
? ClientBuilder.newBuilder().withConfig(config).build()
: ClientBuilder.newBuilder().sslContext(getSslContext()).withConfig(config).build();
}
I checked the "Oracle Cloud Integration" module and it depends on the exported classes to be Jersey 2, this looks like a harder problem.
You can have different versions of the same library, check the Ant Library, there are different versions for JSF and Spring:
[...]
I do not think it is as a matter of "upgrade" but of "support", we should support Jersey 2 for Java/Jakarta EE 8 and prior and add support for Jersey 3 for Jakarta EE 9 and onward.
I agree with @mbien, we should update it to the latest 2.x version.
Understood. Thanks for making it clear. It looks like a matter of having two different directories; ext/jersey2 and ext/jersey3. I'll take look at this.
Ok, my take on this is:
a) jersey is broken because it relies on autodetection of features and does not protect against classes it can't load b) relying on autodiscovery is nice, but broken if you don't control the whole classpath
For "REST Client" I think the solution is trivial (
CommonProperties.FEATURE_AUTO_DISCOVERY_DISABLEdisabled auto detection):
[...]
I have tested it and it works. Thanks a lot!
I checked the "Oracle Cloud Integration" module and it depends on the exported classes to be Jersey 2, this looks like a harder problem.
At least the solution you have posted works for user contributed plugins.
I have created a module for Jersey 3 to avoid conflicts with Jersey 2. It is based on websvc.restlib.
I have updated the PR title and text from the first comment
thanks! all tests were green, removing the label again for subsequent updates.