JIRA 10, plugin REST endpoint returns 405

Hello,

we are currently migrating our plugin to work with the latest Jira version (10). While following the migration guide (rest), we have made several adjustments, but we are encountering issues with the following error in our Jira 10 environment:

Error:
HTTP 405: http://our-jira-test-env:8080/rest/SITVmConnectorBackend/2/SITVmConnectorBackend

The plugin works fine in Jira 9, but in Jira 10, we are seeing this 405 error. Below are the migration steps we have taken:

<rest key="Backend Rest Resources" path="/SITVmConnectorBackend" version="2">
    <description>Provides REST resources for the Backend.</description>
</rest>
<dependency>
    <groupId>com.atlassian.plugins.rest</groupId>
    <artifactId>atlassian-rest-v2-api</artifactId>
    <version>8.0.0</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>javax.ws.rs</groupId>
    <artifactId>javax.ws.rs-api</artifactId>
    <version>2.1</version>
    <scope>provided</scope>
</dependency>
<rest-migration key="rest-migration-key">
    <rest-v2/>
</rest-migration>
<dependency>
    <groupId>javax.inject</groupId>
    <artifactId>javax.inject</artifactId>
    <version>1</version>
    <scope>provided</scope>
</dependency>
@Scanned
@Path("/SITVmConnectorBackend")
public final class BackendServlet extends HttpServlet {
    @ComponentImport
    private final TemplateRenderer templateRenderer;
    private final PluginLicenseManager pluginLicenseManager;
    @ComponentImport
    private final UserManager userManager;
    @ComponentImport
    private final LoginUriProvider loginUriProvider;
    private final ActiveObjects ao;

    @Inject
    public BackendServlet(UserManager userManager, LoginUriProvider loginUriProvider, ...) {
        this.ao = checkNotNull(ao);
        ...
    }

    @POST
    @Path("/")
    @Consumes(MediaType.APPLICATION_JSON)
    @Produces(MediaType.APPLICATION_JSON)
    public Response post(String jsonBody, @Context HttpServletRequest request) {
        ...
    }
}

Despite these changes, we still encounter the HTTP 405 error in Jira 10. The same code works without issue in Jira 9.

Is there anything we may have overlooked or missed in the migration process for Jira 10?

Hi @MartinFischer

please check this article → https://developer.atlassian.com/platform/marketplace/dc-apps-platform-7/#moved-to-jakarta-dependencies

In Jira 10 and Platform 7 you will have to switch to new dependencies.

Cheers
Adam

Hi @adam.labus,

Thank you for your swift response. We have been reviewing the documentation you provided, as well as other articles, including this one, regarding the Platform 7 upgrade (where you discussed it with @MarekTokarski)

We believe we should still be able to use javax imports. Given that our endpoints do not return a 404 status, we assume they are registered as REST v2. However, we are encountering a 405, not really sure what could be causing this.

Hi @MartinFischer

you are using javax as <scope>provided</scope>, but in Jira 10 (Platform 7) I guess Atlassian switched to jakarta and removed access to javax

In my opinion:

  1. you should migrate to jakarta or
  2. switch to javax<scope>compiled</scope> (although I don’t guarantee this option will work)

Personally, I migrated to javax and switched to the Platform’s POM to control the dependency version.

Cheers
Adam

Hi, thank you for your hints and notes.

Migrating to Jakarta isn’t feasible for us at this time due to the many interdependencies between our packages. We are continuing to use javax packages, as they are still supported, particularly given that REST v2 implementation relies on them.

According to the migration guide, the recommended solution to ensure plugin endpoints work with REST v2 is to include the following import:

import javax.ws.rs.*; version="[2.0.0,3.0.0)"

However, we’re wondering if the 405 error status code could be related to the fact that our test Jira 10.0.1 instance is currently running on HTTP rather than HTTPS. We have encountered multiple times that JIRA API responds this way.

Thanks again for your input!

1 Like

For clarification, it seems the main issue was the added path annotation @Path(”/“). For some reason, the ‘root’ path was not handled as we expected. Once we removed it, everything worked well.