IllegalArgumentException: RESTEASY003900 with jersey2-api:2.39-1 #1419
Comments
|
Thanks for the report @jakwarrior . We're investigating the changes in the jersey2 api plugin as part of jenkinsci/bom#1794 . For the moment, you've taken the best path by falling back to the previous release. |
|
I believe the change that caused this issue is in the Jersey 2.39 pull request: That pull request removed the no-args constructor on the DefaultJacksonJaxbJsonProvider class and added a constructor with the |
|
I can confirm that reverting the version to .38 fixes the issue. I had to first uninstall gitlab plugin (and others that depended on jersey), revert jersey and reinstall plugins. Thanks for the tip. |
|
thanks for providing workaround. Will be looking forward for the fix. |
|
I was able to workaround by just downloading both hpi files from the corresponding plugin download sites and uploading both manually through 'Manage Jenkins > Plugin Manager -> Deploy Plugin'. After that a restart was necessary. No issues with deleting other plugins or so. |
I'm not sure when a fix will be available. My time is limited right now so that I'm not able to spend the effort to create a focused example that highlights the incompatibility in Jersey 2.39 compared to Jersey 2.38. I'm not willing to submit an issue to the Jersey project without a focused example that highlights the incompatibility. Ultimately, we hope that the GitLab plugin modernization project idea for Google Summer of Code will replace the use of RESTEasy client with calls to gitlab4j. However, even if that project idea is accepted, it won't be implemented until July-September 2023. If others are willing to create a focused example the highlights the incompatibility in Jersey 2.39 compared to Jersey 2.38, that would be a great help. |
I can confirm that for me installing the jersey-2 plugin via hpi file and reverting the gitlab plugin works as a workaround for this issue. Thanks for the suggestion 😄 |
|
I also confirm. After updating the plugin
Solution:
Thanks everyone!!!!!! |
|
A new release of REST Easy client 3.x has been proposed for inclusion in the plugin with the pull request: It would be much appreciated if one of those affected by this bug could "test drive" the pre-release build of that library update. The pre-release build will be available at https://ci.jenkins.io/job/Plugins/job/gitlab-plugin/view/change-requests/job/PR-1421/ once that job completes successfully. |
|
I encountered this and can confirm that manually installing the previous Jersey 2 API package version 2.38-1 was a temporary workaround while still running GitLab Plugin 1.7.7. @MarkEWaite Tested the gitlab prerelease package. If I understand correctly — this should be used with the latest updated Jersey 2 API plugin (2.39-1 at the time of writing this). Installing the GitLab plugin prerelease package then upgrading Jersey 2 API plugin appears to work well until attempting a webhook. The |
|
I also has tested the PR Build The error still exists with Jersey 2.39-1 |
|
Thanks @trentapple and @MCMicS . I had hoped that we might be lucky and that a fix had been included in the RESTEasy client release. Not as luck as I had hoped. I think the new REST Easy client library is still a good thing to include in the plugin, but it does not resolve this issue. |
|
No Problem. I can also try to find a solution the days or my be create a small focused sample to reproduce |
That would be great! We're much more likely to persuade the Jersey API maintainers of a regression if we have a small focused sample that duplicates the problem and clearly shows that what worked in 2.38 and does not work in 2.39. |
|
Hi @MarkEWaite
Hope it helps I also checked the official examples/docs of jersey but I cannot find any difference. Tested also RestEasy 4.7.9.Final but error is still with this version |
|
Thanks! That looks like it may be a private repository. Would you be willing to either make me @MarkEWaite a collaborator or make it public? |
|
It is now public. |
|
Our users are badly affected by this bug. This fix appears to be incorporated in the RC for 1.7.8, is that correct? If so, how long does it take for the RC to go to released? If I download and install the release candidate, will the next version be recommended when it's available, or will I have to uninstall the RC and reinstall the plugin? https://ci.jenkins.io/job/Plugins/job/gitlab-plugin/job/master/ |
|
I see @basil has two pending pull requests to fix this issue in jenkinsci/jersey2-api-plugin#60 and jenkins-infra/update-center2#688. Once those are merged, I will cut a new release if no one else get to that yet. |
|
The Jersey 2.39 upgrade has been reverted in jenkinsci/jersey2-api-plugin#60, and the Jersey 2 API plugin 2.39-1 has been suspended from distribution in jenkins-infra/update-center2#688. Affected users should downgrade Jersey 2 API plugin from 2.39-1 to 2.38-1. |
|
As of jenkinsci/jersey2-api-plugin#61 the Jersey 2 API plugin test suite tests compatibility with RESTEasy 3.15.x. These tests pass on Jersey 2.38 and fail on Jersey 2.39. The new tests ensure that all future releases of Jersey 2 API plugin will be compatible with RESTEasy 3.15.x and therefore GitLab plugin. |
|
Same problem, |
jenkinsci/gitlab-plugin#1419 reports that jersey2 api 2.39 broke compatibility with jersey2 api 2.38 and causes an 'IllegalArgumentException: RESTEASY003900' jenkins-infra/update-center2#688 suspends jersey2 api plugin 2.39-1 from distribution. Since the jersey2 api plugin 2.39-1 is suspended from distribution, it should not be used in my standard environment. I've not detected the issues myself, but want the environment to use available plugins. This reverts commit 12efef6.
Correct. It was noted in an earlier comment that the current known workaround is to downgrade the Jenkins jersey2-api plugin from 2.39-1 to 2.38-1. If the jersey2-api plugin was upgraded from the Jenkins plugin manager, then there will be a downgrade option available in the plugin manager. If the jersey2-api plugin was upgraded with the plugin installation manager tool, then the plugins definition (plugins.txt or plugins.yaml) needs to be changed to use 2.38-1 instead of 2.39-1. The jersey2-api plugin 2.39-1 has been suspended from distribution (thanks to @basil) so that users will no longer be able to install that version. |
We install and upgrade all plugins from the manager. We have the 1.7.8 version of Gitlab API install. However, the downgrade option is not available for jersey2-api, it is greyed out. Any idea why that would be? |
|
@jonl-percsolutions-com I would suggest to download the hpi file for 2.38-1 and upload it manually to replace your current version. Or if you have access to the jenkins instance restore the previous hpi file (name with Url to Deploy: https://updates.jenkins.io/download/plugins/jersey2-api/2.38-1/jersey2-api.hpi |
|
It appears that nothing else depends on it other than gitlab-plugin. I ran a script in the console that lists all plugins and dependencies and version. If I'm not missing anything, then I will report a bug. |
|
can you deploy it manually? disabe plugin (and rollback) is not possible and shown in tooltip. |
|
The plugin release revocation is intransparent and non-obvious. (I would have said horrendously misleading, but I may have misunderstood which version displayed shows what - which is another non-obvious, bad UI issue making the whole revokation UX worse.) I had to manually track this issue down and rename the files in @MCMicS You can check for the files Then you drop the v2.39 file and use (rename) the v2.38 file to |
|
The v1.7.8 release does not mention jersey-api. What's the relationship between v1.7.8 and jersey-api? It mentions resteasy-client - does that depend on or is defined in jersey-api? (I don't see an installed plugin called resteasy-client in Jenkins.) |
The GitLab plugin depends on the Jersey 2 API plugin. A reference to the Jersey 2 API plugin is inserted into the GitLab plugin when the GitLab plugin is compiled. The Jersey 2 API plugin must be installed in Jenkins in order to run the GitLab plugin. See the brief description of API plugins for more information. The GitLab plugin depends on the RESTEasy client API jar file. A copy of the RESTEasy client API jar file is inserted into the GitLab plugin when the GitLab plugin is compiled. The RESTEasy client API is not widely used in Jenkins. Converting it to an API plugin would not help Jenkins plugin maintainers enough to be worth the effort. The RESTEasy client API jar file uses the Jersey 2 API in its implementation. The RESTEasy client API depends on the Jersey 2 API. My hope was that the update from RESTEasy client API 3.15.3.Final to 3.15.6.Final might resolve the issue. That hope was incorrect. As shown by @MCMicS, the problem is in the Jersey 2 API 2.39. |
Yes, suspending a plugin does not have a UI to support it. Thankfully, it is very rare that we suspend distribution of a plugin. Suspending distribution of a plugin prevents download but does not remove the plugin from existing installations. It requires additional steps from users if they want to remove or replace the suspended plugin. |
|
Deploy Jersey in release 2.38 solve the problem in the gitlab plugin. |
|
This ticket should now be closed, as this issue has been resolved. I would like to thank @MCMicS for contributing the minimal reproducible example (MRE) at Mark's request. Not only was I able to use this to add a test case to A rising tide lifts all boats. When one open source project benefits, we all benefit. |
|
Thanks to all involved! |
Jenkins and plugins versions report
Environment
What Operating System are you using (both controller, and any agents involved in the problem)?
Ubuntu 20.04
Reproduction steps
I have a pipeline job that looks like this:
Expected Results
I expect to have no errors.
Actual Results
With jersey2-api:2.39-1, I have this stacktrace:
Anything else?
Everything is fine with gitlab-plugin:1.7.7 and jersey2-api:2.38-1. There is a regression with jersey2-api:2.39-1.
The text was updated successfully, but these errors were encountered: