6.2.3.Final

[jamezp]

What's Changed

• Backports to 6.2 by @jamezp in Backports to 6.2 #3423
• Revert - [RESTEASY-2845] ResteasyWebTarget.proxy(Class) problem with questionmark in @path with Regex by @jamezp in Revert - [RESTEASY-2845] ResteasyWebTarget.proxy(Class) problem with questionmark in @Path with Regex #3432
• [RESTEASY-3290] Avoid an NPE if the temporary directory is null and e… by @jamezp in [RESTEASY-3290] Avoid an NPE if the temporary directory is null and e… #3436
• Bump httpasyncclient from 4.1.4 to 4.1.5 by @dependabot in Bump httpasyncclient from 4.1.4 to 4.1.5 #3451
• Bump wildfly-cli from 19.0.0.Final to 19.0.1.Final by @dependabot in Bump wildfly-cli from 19.0.0.Final to 19.0.1.Final #3454
• Bump version.org.eclipse.jetty from 11.0.13 to 11.0.14 by @dependabot in Bump version.org.eclipse.jetty from 11.0.13 to 11.0.14 #3458
• Bump version.org.wildfly.galleon-plugins from 6.2.0.Final to 6.2.3.Final by @dependabot in Bump version.org.wildfly.galleon-plugins from 6.2.0.Final to 6.2.3.Final #3459
• Bump jackson-databind from 2.13.4.2 to 2.13.5 by @dependabot in Bump jackson-databind from 2.13.4.2 to 2.13.5 #3465
• Bump version.com.fasterxml.jackson from 2.13.4 to 2.13.5 by @dependabot in Bump version.com.fasterxml.jackson from 2.13.4 to 2.13.5 #3453
• Bump galleon-maven-plugin from 5.0.6.Final to 5.0.8.Final by @dependabot in Bump galleon-maven-plugin from 5.0.6.Final to 5.0.8.Final #3464
• Bump maven-jdocbook-plugin from 2.3.9 to 2.3.10 by @dependabot in Bump maven-jdocbook-plugin from 2.3.9 to 2.3.10 #3481
• Bump arquillian-bom from 1.7.0.Alpha13 to 1.7.0.Alpha14 by @dependabot in Bump arquillian-bom from 1.7.0.Alpha13 to 1.7.0.Alpha14 #3473
• Upgrade Arquillian Weld by @jamezp in Upgrade Arquillian Weld #3484
• [RESTEASY-3295] Upgrade Jackson to 2.14.2. by @jamezp in [RESTEASY-3295] Upgrade Jackson to 2.14.2. #3501

Full Changelog: 6.2.2.Final...6.2.3.Final

---

This discussion was created from the release 6.2.3.Final.

[erdi]

I know that this is quite old but we started getting alerts for GHSA-2c6g-pfx3-w7h8 which you opened a couple of days ago, @jamezp. I don't understand why we weren't getting alerts for GHSA-jrmh-v64j-mjm9 which GHSA-2c6g-pfx3-w7h8 duplicates but that's another matter.

My question is - would it be possible, please, to backport #3423 for those of us who are on Jakarta EE 9 and therefore confined to the 6.0.x line of RESTeasy? I find it somewhat surprising that this was backported for Jakarta EE 8 (RESTEasy 5.0.6) and Jakarta EE 10 (RESTeasy 6.2.3) but not Jakarta EE 9 (RESTEasy 6.0.x). Was that intentional or an omission?

[jamezp]

This was an intentional omission. Is there a reason you're not able to use Jakarta REST 3.1 and RESTEasy 6.2? I'm only asking because RESTEasy 6.0 is effectively dead. Jakarta EE 9 was really meant as an intermittent release to migrate the namespace.

[erdi]

Thanks for your reply, it's appreciated.

The main reason why we are sticking to Jakarta EE 9 for now is that last time I checked not all of our dependencies have published a Jakarta EE 10 compatible version. It's been a while since then, so maybe that's changed and it's time to revisit.

Jakarta EE 9 was really meant as an intermittent release to migrate the namespace.

Fair enough but it's somehow surprising that you keep support for an earlier Jakarta EE specification but not for that one given how painful migration to EE 9 was for a lot of folks especially on large codebases.

[jamezp]

The main reason why we are sticking to Jakarta EE 9 for now is that last time I checked not all of our dependencies have published a Jakarta EE 10 compatible version. It's been a while since then, so maybe that's changed and it's time to revisit.

That is fair. I'm not aware of an Jakarta EE 9 components that will not work with Jakarta EE 10. However, I understand that doesn't mean you can simply just upgrade :)

Fair enough but it's somehow surprising that you keep support for an earlier Jakarta EE specification but not for that one given how painful migration to EE 9 was for a lot of folks especially on large codebases.

TBH this is the first issue I've seen against the Jakarta REST 3.0 release :) I didn't even know it was really being used.

That said, 5.0 is now no longer being released. I did back port this to 3.15.x because it's used in JBoss EAP 7.4. I ported it to 4.7 because that is used in WildFly 26, even though there are no more releases of WildFly 26 either.

FWIW the changes between Jakarta REST 3.0 and Jakarta REST 3.1 are fairly minimal https://jakarta.ee/specifications/restful-ws/3.1/jakarta-restful-ws-spec-3.1#changes-since-3.0-release.

[erdi]

Apologies for a late reply, this fell through the cracks.

I didn't even know it was really being used.

On the contrary, I would actually expect a lot of people to be on Jakarta EE 9 versions of specifications because not all projects have yet implemented Jakarta EE 10 versions of them. Or at least that was the case until fairly recently. In our case we even had to wait for Jakarta EE 9 (!) compatible release of Guice.

FWIW the changes between Jakarta REST 3.0 and Jakarta REST 3.1 are fairly minimal

That's fair but bear in mind that while RESTeasy only depends on a single Jakarta EE specification, we are using projects which depend on Jakarta REST and another specification and then we use other projects which depend on that and yet other ones so in essence we have to upgrade the whole lot of Jakarta EE specifications in one go.

[jamezp]

I know that WildFly never shipped with just Jakarta EE 9 support so that could be why I'm not aware of how much it's used.

I can say, the Eclipse MicroProfile specifications were based on Jakarta EE 9, this changed in MicroProfile 7, and they worked with all the Jakarta EE 10 components in WildFly.

All that said, I'm not sure we want to support RESTEasy 6.0. There would be A LOT of back ports needed as 6.2 and 7.0 are currently the only two streams seeing updates. The 6.0 branch has not seen any updates in 3.5 years.

I truly do understand having this security notice is annoying. I really can't think of any issues that would come up with upgrading to Jakarta REST 3.1 and RESTEasy 6.2. The specification and implementation are backwards compatible.

[erdi]

Thanks for your replies and bearing with me, @jamezp. All you are saying is very reasonable even if it does not make our lives in any way easier. Oh well, I guess an upgrade is the only way forward for us, thanks.

[jamezp]

Not a problem at all @erdi. I appreciate the feedback and please feel free to ask anything. This was a great question as I truly had no idea people were using RESTEasy 6.0 :)