Within one of our plugins we get a 404 in every REST call. This only happens in Jira 8.7.1. All prior versions (including 8.7.0) are fine with the exact same jar.
Another plugin of us doesn’t has this issue either, but (until now) we could’t find any difference in any xml file or service that could cause this.
It’s not depending on the environment or machine, we tested a few different ones.
Has anyone here experienced a similar issue or does have an idea, what could be causing it?
can you verify that your plugin is loaded / that the rest component of your plugin is loaded?
Typically 404 errors occur if the plugin/component is not available.
The plugin is loaded and activated and all components/modules are enabled, too.
and I’d assume you have freshly compiled the app against Jira 8.7.1 to rule out any dependency problems.
Is there anything you can see in the logfiles?
I have exactly the same issue. 404 for every call of the REST API for a certain plugin. And no trace of a problem. Plugin manager says REST API component is activated successfully.
Last thing that you can verify: Do you have annotations e.g. @Consumes. Does the request Content-Type match the type specified in the annotation?
We have seen this error previously and this also leads to 404 errors.
But @Consumes worked perfectly before with Jira 8.6. The issue comes only when using Jira 8.7.1 (using atlas-run --version 8.7.1). I am using Atlas SDK Mac 8.0.7 with AMPS 8.0.0.
We got it to work after deleting the usage of a class (UserPickerResourceHelperImpl).
But we still don’t know, why this class is not available anymore and why no error was thrown anywhere.
@Holger & @JanvandeLoo – just reached out to the Jira Server team to see if they have any insight as to what is causing this issue for you. Will let you know what we find out.
I was able to resolve my issue.
I had a wrong class in my REST web service constructor, which didn’t work for constructor-based injection and therefor created an error for the all REST web services setup of my plugin.
I removed CustomFieldContextConfigHelper from constructor-based injection and everything is now working as expected.