Hi @riteshshah
I see the error refers to com/atlassian/greenhopper/service/sprint/SprintService. It is Jira specific code. Unfortunately I don’t know what happened there. I would recommend reaching Jira team directly.
@MarekTokarski ,
Thanks for the reply, How can I reach to Jira team. Can you please help me for that ?
Hi,
We’re trying to use REST v2. We are using these packages
<dependency>
<groupId>jakarta.ws.rs</groupId>
<artifactId>jakarta.ws.rs-api</artifactId>
<version>2.1.6</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.atlassian.plugins.rest</groupId>
<artifactId>atlassian-rest-v2-api</artifactId>
<version>8.0.0-m14</version>
<scope>provided</scope>
</dependency>
Our REST endpoints work but with each call we get this warning/error in the log
[INFO] [talledLocalContainer] INFO: Initiating Jersey application, version 'Jersey: 1.19.5-atlassian-17 e82a5696e4ec99aa82f929706300af9a18da3870'
[INFO] [talledLocalContainer] 17:10:30,644 WARN [http-nio-1990-exec-8] [jersey.internal.Errors] logErrors The following warnings have been detected: WARNING: HK2 service reification failed for [com.example.atlassian.plugin.web.DraftResource] with an exception:\nMultiException stack 1 of 2\njava.lang.NoSuchMethodException: Could not find a suitable constructor in com.example.atlassian.plugin.web.DraftResource class.\n\tat org.glassfish.jersey.inject.hk2.JerseyClassAnalyzer.getConstructor(JerseyClassAnalyzer.java:168)\n\tat org.jvnet.hk2.internal.Utilities.getConstructor(Utilities.java:156)\n\tat org.jvnet.hk2.internal.ClazzCreator.initialize(ClazzCreator.java:105)\n\tat org.jvnet.hk2.internal.ClazzCreator.initialize(ClazzCreator.java:156)\n\tat org.jvnet.hk2.internal.SystemDescriptor.internalReify(SystemDescriptor.java:716)\n\tat org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:670)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:442)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:2300)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl.igdCacheCompute(ServiceLocatorImpl.java:1176)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl.access$400(ServiceLocatorImpl.java:106)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl$8.compute(ServiceLocatorImpl.java:1170)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl$8.compute(ServiceLocatorImpl.java:1167)\n\tat org.glassfish.hk2.utilities.cache.internal.WeakCARCacheImpl.compute(WeakCARCacheImpl.java:105)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:1250)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetService(ServiceLocatorImpl.java:754)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetService(ServiceLocatorImpl.java:721)\n\tat org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:691)\n\tat org.glassfish.jersey.inject.hk2.AbstractHk2InjectionManager.getInstance(AbstractHk2InjectionManager.java:161)\n\tat org.glassfish.jersey.inject.hk2.ImmediateHk2InjectionManager.getInstance(ImmediateHk2InjectionManager.java:30)\n\tat org.glassfish.jersey.internal.inject.Injections.getOrCreate(Injections.java:122)\n\tat org.glassfish.jersey.server.model.MethodHandler$ClassBasedMethodHandler.getInstance(MethodHandler.java:260)\n\tat org.glassfish.jersey.server.internal.routing.PushMethodHandlerRouter.apply(PushMethodHandlerRouter.java:51)\n\tat org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:86)\n\tat org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:89)\n\tat org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:89)\n\tat org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:89)\n\tat org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:89)\n\tat org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:69)\n\tat org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:38)\n\tat org.glassfish.jersey.process.internal.Stages.process(Stages.java:173)\n\tat org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:248)\n\tat org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)\n\tat org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)\n\tat org.glassfish.jersey.internal.Errors.process(Errors.java:292)\n\tat org.glassfish.jersey.internal.Errors.process(Errors.java:274)\n\tat org.glassfish.jersey.internal.Errors.process(Errors.java:244)\n\tat org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)\n\tat org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:235)\n\tat org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:684)\n\tat org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:394)\n\tat org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:346)\n\tat org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:359)\n\tat com.atlassian.plugins.rest.v2.jersey.JerseyOsgiServletContainer.doFilter(JerseyOsgiServletContainer.java:74)\n\tat org.glassfish.jersey.servlet.ServletContainer.doFilter(ServletContainer.java:432)\n\tat com.atlassian.plugins.rest.v2.servlet.RestDelegatingServletFilter.doFilter(RestDelegatingServletFilter.java:80)\n\tat com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:62)\n\tat com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:37)\n\tat com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:56)\n\tat com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:44)\n\tat com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:62)\n\tat com.atlassian.confluence.plugin.servlet.filter.AccessCheckPluginDelegateFilter.doFilter(AccessCheckPluginDelegateFilter.java:34)\n\tat com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:37)\n\tat com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.lambda$doFilter$0(DelegatingPluginFilter.java:57)\n\tat com.atlassian.confluence.plugins.baseurl.IncludeResourcesFilter.doFilter(IncludeResourcesFilter.java:52)\n\tat com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:32)\n\tat com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:62)\n\tat com.atlassian.confluence.plugin.servlet.filter.AccessCheckPluginDelegateFilter.doFilter(AccessCheckPluginDelegateFilter.java:34)\n\tat com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:37)\n\tat com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.lambda$doFilter$0(DelegatingPluginFilter.java:57)\n\tat com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:39)\n\tat com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:56)\n\tat com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:44)\n\tat com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:62)\n\tat com.atlassian.confluence.plugin.servlet.filter.AccessCheckPluginDelegateFilter.doFilter(AccessCheckPluginDelegateFilter.java:34)\n\tat com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:37)\n\tat com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.lambda$doFilter$0(DelegatingPluginFilter.java:57)\n\tat ...
Also, in https://developer.atlassian.com/platform/marketplace/dc-apps-platform-7/ it says Platform 7 moved from javax ones to jakarta but REST v2 uses jakarta.ws.rs-api:2.1.6 is still using javax.ws.rs and using the latest version breaks the plugin.
Can you please help
Thanks
1 Like
The warning/error you are getting complains about com.example.atlassian.plugin.web.DraftResource. I assume it is your class (it starts with com.example) and not Atlassian provided. Based on the error message I suspect the resource lack @Inject annotation that is required on REST v2 resources.
Regarding Javax/Jakarta. I’m sorry for the confusion, I will try to make it clearer. We moved Maven dependencies to Jakarta (e.g. groupId starts with jakarta.*). We are still using Jakarta 8 that is an equivalent of latest Javax version. The change affects only Maven dependencies definition (if you are using Platform to manage the dependencies). If you are managing dependencies on your own, you can use dependency as you used to. We are not migrating the code to jakarta.* namespace in Platform 7. I hope it explains the ambiguity 
4 Likes
Hi @adam.labus
I’m sorry for the confusion. In Platform 7 we aim to consistently use Jakarta 8 dependencies. It is a change on a Maven level. There is no change in the code namespace. Jakarta 8 still uses javax.* packages an moved to jakarta.* only in Jakarta 9+. Platform 7 relies on javax.* packages To compile our code we are using Jakarta 8 artifacts (that start with jakarta.* in their groupId/artifactId).
4 Likes
thank you very much for explanation
My problems and doubts also resulted from this thread - Preparing for Confluence 9.0 - EAP coming soon - #142 by adam.labus
Additionally, I read https://developer.atlassian.com/platform/marketplace/dc-apps-platform-7/#moved-to-jakarta-dependencies and checked what was underneath and I managed to efficiently switch to the new jakarta.* dependencies in pom.xml (from Platform 7) as well as handle jakarta.xml.bind.Marshaller and Unmarshaller
Cheers
Adam
Hi @MarekTokarski,
Thanks for your help that you provide here. I’ve followed your answers and managed to make part of the REST v2 migration work for a plugin on Jira v10.0.0-m0002.
Except that when I remove the dependency to jsr311-api and replaced it with jakarta.ws.rs-api, I get no compilations errors, but I get a 404 on my endpoints.
<status>
<status-code>404</status-code>
<message>HTTP 404 Not Found</message>
</status>
Do you have any clue what is causing this issue? Is the library replacement mandatory?
Thanks
1 Like
Hi @RobinDelmas
The dependency you are using in Maven has little in common of what is actually hapenning at runtime. It seems that your plugin isn’t properly registered in REST v2. There are various issues of that situations. Please check things like:
- host product logs - any errors related to your plugin
- is your plugin enabled
- what modules are defined for your plugin (check UPM tab)
- what are the imports/exports of your plugin and to which other plugins it is wired to (you can find that information on the OSGi tab -
<base_url>/plugins/servlet/upm/osgi)
From my experience typical issues are:
rest-migration/rest-v2module definition missing inatlassian-plugin.xml- incorrect OSGi exports (wrong type - missing from the host, incorrect version range)
- missing
@Injectannotation in resource constructor - some other autowiring issues that can be found in logs
1 Like
Thanks, that fixed the problem
Hi,
We are experiencing a chain dependency conflict when using Atlassian REST V2 along with mywork-api in Confluence 9.0.0-m48, can you help with this?
<dependency>
<groupId>com.atlassian.mywork</groupId>
<artifactId>mywork-api</artifactId>
<version>19.0.15</version>
<scope>provided</scope>
</dependency>
Caused by: org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve resource com.mute.confluence.plugins.lms [com.mute.confluence.plugins.lms [299](R 299.0)] because it is exposed to package 'javax.ws.rs.core' from resources com.atlassian.plugins.rest.atlassian-rest-v2-plugin [com.atlassian.plugins.rest.atlassian-rest-v2-plugin [163](R 163.0)] and org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two dependency chains.
Chain 1:
com.mute.confluence.plugins.lms [com.mute.confluence.plugins.lms [299](R 299.0)]
import: (osgi.wiring.package=javax.ws.rs.core)
|
export: osgi.wiring.package: javax.ws.rs.core
com.atlassian.plugins.rest.atlassian-rest-v2-plugin [com.atlassian.plugins.rest.atlassian-rest-v2-plugin [163](R 163.0)]
Chain 2:
com.mute.confluence.plugins.lms [com.mute.confluence.plugins.lms [299](R 299.0)]
import: (osgi.wiring.package=com.atlassian.mywork.model)
|
export: osgi.wiring.package=com.atlassian.mywork.model; uses:=javax.ws.rs.core
com.atlassian.mywork.common-plugin [com.atlassian.mywork.common-plugin [129](R 129.0)]
import: (osgi.wiring.package=javax.ws.rs.core)
2 Likes
Hi,
We are currently trying to make the production version of one of our apps compatible with Confluence 7.19.0 through 9.0.0 and are encountering some problems. We have managed to create working .jars for each version and are now trying to unify them into a single .jar that works with all versions at the same time.
The app defines a rest module. We manged to build a .jar that works with Confluence 7.19.0, 8.9.0 and 9.0.0-m30 at the same time by adding restrict tags as suggested by @scott.dudley above and marking some REST v1 & REST v2 import-packages as optional in our MANIFEST.MF:
<rest-migration key="myKey" name="myName">
<restrict application="confluence" version="[8.999,)" />
<rest-v2/>
</rest-migration>
<rest key="rest-resource" path="/">
<restrict application="confluence" version="(,8.999)" />
<package>com.my.app.compatibility.rest.v1</package>
</rest>
<rest key="rest-resource" path="/">
<restrict application="confluence" version="[8.999,)" />
<package>com.my.app.compatibility.rest.v2</package>
</rest>
During testing, we noticed that this solution breaks on Confluence 8.8.0: Whenever the rest-migration module is present (with or without the restrict tag), our rest module fails to enable. No other app modules are affected. After some digging we uncovered the following log statements:
15:59:57,782 INFO [UpmAsynchronousTaskManager:thread-2] [osgi.factory.UnrecognisedModuleDescriptorFallbackFactory] getModuleDescriptor Unknown module descriptor of type rest registered as an unrecognised descriptor.
...
15:59:59,427 DEBUG [UpmAsynchronousTaskManager:thread-2] [plugin.manager.DefaultPluginManager] lambda$enableConfiguredPluginModule$32 Plugin module 'rest-resource' is explicitly disabled (or so by default), so not re-enabling.
Does anyone know how to resolve this problem?
As of right now, we are hoping that the rest-migration module will no longer be needed with the proper release of Confluence 9.0.0 as rest v2 will become the new default. Is this confirmed to be true?
Another option might be to try and ‘manually’ re-enable the rest module at runtime. Is there a good way to do that?
3 Likes
Although the <restrict> tags work for most module types, @rlander discovered a kludge buried in the package resolution process. I have not tested, but this makes it seem as if the restrictions are completely ignored with regards to the <rest-v2/> migration tag…so I am guessing that the <restrict> for that one particular module will behave as if it were not restricted after all.
Thanks for the input!
That’s also what we suspect. There is another mention of rest-migration in the UnrecognizedModuleDescriptorServiceTrackerCustomizer class. Looks like the <restrict> tags are also ignored there. Since our rest module is initially marked as unrecognized and the mentioned class seems to be partially responsible for resolving unrecognized modules, this might be where the problem originates?
Other than that, digging through the code base has not been very fruitful for us. We were hoping someone else might have encountered a similar problem already?
Hi Here,
We’re working on Confluence 9 compatibility for our app. We got the app working on confluence 9 but when we try to test the backward compatibility of same jar in confluence 8, we see the below exception on installing the application,
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.atlassian.confluence.content.CustomContentManager' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@com.atlassian.plugin.spring.scanner.annotation.imports.ComponentImport("")}
at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1801)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1357)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1311)
Please note that CustomContentManager is coming from the confluence jar and its available in Confluence 9.x and Confluence 8.x jar as well.
Any help is appreciated. Thanks
1 Like
I see that version 7.0.0 has already been officially “released” and subsequent versions are being developed (Index of maven-atlassian-external/com/atlassian/platform/dependencies/platform-public-api/7.0.0)
Question - can you determine which version of Platform 7 (7.0., 7.1., 7.* or other) will ultimately be released with Confluence 9 and/or Jira 10?
Cheers
Adam
2 Likes
Hi Team,
I am trying to instantiate UserManger in the constructor of rest resource to support Rest v2 feature as below.But none of the api is working as mentioned below
- ComponentLocator.getComponent(com.atlassian.sal.api.user.UserManager.class);. This api is returning null
- ContainerManager.getComponent(“userManager”, com.atlassian.sal.api.user.UserManager.class);
is throwing below exception as the above is returning com.atlassian.user.UserManager.class instead of com.atlassian.sal.api.user.UserManager.class
Caused by: A MultiException has 2 exceptions. They are:
1. com.atlassian.spring.container.ComponentTypeMismatchException: Component 'userManager' of type 'class jdk.proxy4.$Proxy224' cannot be assigned to requested type 'interface com.atlassian.sal.api.user.UserManager'
2. java.lang.IllegalStateException: Unable to perform operation: create on RestResource
Let me know how to solve this or any other way to access atlassian components in Rest v2 no arg
constructor.
Thanks,
Aparna .
Hi,
Did you finally resolve this chain dependency conflict with mywork-api ?
If not, how could we resolve it ?
No, we did not; we are still waiting for an update in relation to the dependency conflict with mywork-api
Hiya, does the Prepare your Data Center app for Platform 7 page need updated? Mainly to update dependencies from their milestone versions (eg x.x.x-m03) to full releases.
For example, Active Objects is listed as 6.0.0-m03, but 6.0.1 is being provided through the platform-public-api BOM.
Or, am I misunderstanding? Is it intentional that the milestone versions are listed as they are the “earliest available” versions to support platform 7?
I’d also like to second the comment by @adam.labus about confirming the version of Platform 7 shipped with Confluence 9 / Jira 10. Although, that may be a question for those product teams on the respective EAP threads, so happy to ask there instead.
Cheers!
1 Like