Supporting REST v1 until last version of products with “REST v1 only” will reach EOL would take us couple more years to get rid of REST v1 completely.
I understand the disaffection. We need to catch-up with the solutions like this. We are doing this step now, so we can regularly update our environment in the future and provide easier-to-migrate platform.
Hi @adam.labus
The only public documentation about REST v2 right now is Bitbucket.
To answer your question here - we tried to provide up-to-date ecosystem that meets the security and quality standards for our customers. The change wasn’t driven by improvements for plugin developers/partners, but we are open for any suggestions in the future.
Despite it wasn’t our first goal, I think you can also benefit from the REST v2:
“Supporting REST v1 until last version of products with “REST v1 only” will reach EOL would take us couple more years to get rid of REST v1 completely.”
From the vendor’s perspective, that approach means a couple of years (not more, because until now, we were able to support a huge scope of Jira’s versions with a single release) of maintaining two or more separate plugin releases (jar files).
I think that we will just put more effort into reflection-based hacking approaches to have one code working with v1 or v2.
Hi 
We made the decision to export Jackson 2 components to the Plugin System:
com.fasterxml.jackson.core:jackson-annotationscom.fasterxml.jackson.core:jackson-corecom.fasterxml.jackson.core:jackson-databindFor more information and/or discussion, please use Platform 7 will contain exports of Jackson 2
Hi,
Anyone knows how to implement Attachment Text Extractor in Platform 7/Confluence 9
The steps in this tutorial
https://developer.atlassian.com/server/confluence/attachment-text-extractor-module-tutorial/
uses InputStreamSource from package com.atlassian.confluence.util.io
This package is showing a warning that package com.atlassian.confluence.util.io is not available.
WARN [main] [hook.dmz.DmzResolverHook] filterMatches Package com.atlassian.confluence.util.io is internal and is not available for export to plugin
Thanks
Hi there,
I’ve come across the following error:
java.lang.RuntimeException: javax.servlet.ServletException:
org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getConfluenceResourceTags' in class com.atlassian.confluence.setup.velocity.VelocityFriendlyPageBuilderService threw exception java.lang.AbstractMethodError:
Receiver class com.myapp.confluence.condition.CustomUrlReadingCondition does not define or inherit an implementation of the resolved method 'abstract void addToUrl(com.atlassian.plugin.webresource.url.UrlBuilder)' of interface com.atlassian.plugin.webresource.condition.UrlReadingCondition. at /decorators/includes/header.vm[line 93, column 24]
My class CustomUrlReadingCondition implements all methods from com.atlassian.webresource.spi.condition.UrlReadingCondition (docs), but it seems that Confluence still uses the old one com.atlassian.plugin.webresource.condition.UrlReadingCondition.
The environment: Confluence 9.0.0-m26, 9.0.0-m23
Does someone know how to deal with it, or do I need to wait for new Confluence EAP versions?
Is there a release date for the milestone of atlassian-plugins-webresource?
Hi all,
I have followed the guide to update our app to use REST v2, using Bitbucket 8.19.0, and after updating dependencies, refactoring filters, resources etc, fixing all the compilation issues, I still have runtime errors when the app starts, giving me errors of type ‘The ResourceConfig instance does not contain any root resource classes.’
I have also noticed that jakarta.ws.rs:jakarta.ws.rs-api is not included in the system bundle which makes me suspect that Bitbucket 8.19.0 has not done the switch to REST v2 yet?
Could we please confirm that we can use platform 6.5 with bitbucket (8.18 or higher) to test the REST v2 update with a fully working app?
Has anyone managed to use REST v2 with Bitbucket so far?
We are working on making com.atlassian.confluence.util.io. InputStreamSource public API again. That should help you implement the AttachmentTextExtractor.
We will let you know once the change is available in the future 9.0 EAP release.
Thanks,
Mahesh
To be 100% correct jakarta.ws.rs:jakarta.ws.rs-api should be exported by the REST v2 plugin and not the “System Bundle”.
That being said I checked Bitbucket 8.19.1 and it seems it doesn’t contain REST v2 despite using Platform 6.5 
I will try to reach Bitbucket team directly to understand their plans for introducing REST v2.
Great to hear you were able to migrate your code! From what I know Confluence is still working on migrating to the new WRM API (there were more internal changes). They should provide an update in one of the following milestones. Please reach to the Confluence team directly to get more information.
Thanks for checking @MarekTokarski
If you have any updates or rough dates on when to expect an EAP for Bitbucket 9, that would great!
Any information about this @MarekTokarski ?
I’m sorry, this is Jira specific issue. I would recommend waiting for someone from the Jira team to respond in the original thread.
Was file upload removed from REST API v2?
With the REST API v1, we use com.atlassian.plugins.rest.common.multipart.FilePart and com.atlassian.plugins.rest.common.multipart.MultipartFormParam to be able to upload a file. It is not available in REST API v2. I can see the (other) package com.atlassian.plugins.rest.api.multipart which contains those classes, but they are unusable. At runtime, we get:
[INFO] [talledLocalContainer] INFO: Initiating Jersey application, version 'Jersey: 1.19.4 05/24/2017 03:20 PM'
[INFO] [talledLocalContainer] 2024-04-08 21:14:29,361 ERROR [http-nio-1991-exec-1] [atlassian.plugin.servlet.DefaultServletModuleManager] getInstance Unable to create new reference LazyLoadedFilterReference{descriptor=com.playsql.requirementyogi:rest-filter (REST API for Requirement Yogi), filterConfig=com.atlassian.plugin.servlet.filter.PluginFilterConfig@7a531a9}
[INFO] [talledLocalContainer] io.atlassian.util.concurrent.LazyReference$InitializationException: java.lang.TypeNotPresentException: Type com.atlassian.plugins.rest.api.multipart.FilePart not present
It says “Type not present”, not “Class not found” for @MultipartFormParam FilePart:
Code snippet:
@Path("/upload")
@POST
@Consumes(MediaType.MULTIPART_FORM_DATA)
@Produces(JSON_UTF8)
public Response uploadFile(@MultipartFormParam("file") List<FilePart> fileParts) {
Hi,
It is hard to understand what is actually going on. Everything from packages like com.atlassian.plugins.rest.api is accessible to all plugins. Did you check if your OSGi imports are correct? Additionally the line:
[INFO] [talledLocalContainer] INFO: Initiating Jersey application, version 'Jersey: 1.19.4 05/24/2017 03:20 PM'
suggests that the plugin uses REST v1. Perhaps you are trying to use REST v2 types in REST v1 context.
Thank you Marek, noticing that there was a log about Jersey 1 made me notice which packages from REST API v1 we still used.
For others: Concerning the Import-Package for com.atlassian.plugins.rest.common.multipart vs api.multipart, I have simply created 2 <rest ... declarations, one for Confluence 8.9 and one for pre-8.9, and I use an InitializingBean#afterPropertySet() to extract the Confluence version, and activate one package or the other. Thank you Marek for the help.
Hi @MarekTokarski ,
I am trying to check our plugin in jira 10 EAP, but not able to enable our plugin and getting following error:
failed; nested exception is java.lang.NoClassDefFoundError: com/atlassian/greenhopper/service/sprint/SprintService
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.resolveFieldValue(AutowiredAnnotationBeanPostProcessor.java:713)
Till JIra v9.15 it is working fine. Please guide me to resolve this error.
I’m not sure if you’re talking about activating plugin modules or actual OSGi packages, but in the former case, Jens R pointed out earlier that you don’t even need to do this dynamically. You can use <restrict> in atlassian-plugin.xml module definitions to achieve the same effect:
<rest-migration key="myKey" name="myName">
<restrict application="confluence" version="(8.999,)" />
<rest-v2/>
</rest-migration>
<some-other-module key="myKey2" name="myName2">
<restrict application="confluence" version="(,8.999)" />
</some-other-module>
(I used “8.999” here to mean 9.0 and up, because “9.0” doesn’t seem to compare as one would expect when using a 9.0.0-mXX milestone release.)
TIL restrict is a module parameter
This might actually fix something we’ve just bumped into…
Thank you very much again, @scott.dudley , indeed it seems <restrict> was introduced at one point, which is VERY helpful. Here is the link to Jens’ message, which serves as documentation.