we have a rather strange issue, only occuring in Jira 7 and some Jira 8 versions, i.e. 8.1.1.
For the recent Jira 8.5.1 this has never been a problem. Stack trace is the below, causing custom REST endpoints not to load. We’ve did everything already in terms of path annotations in the resource class, checking the atlassian-plugin.xml REST reference without no luck. Basically tried all the things you can find on the web. I’ve seen a post that an Atlassian support tool plugin suffered from the same once and I was wondering what the fix was ([ATST-233] - Ecosystem Jira). Diffing 3.0.25 and .26 at least does not provide too much, at least not in the class with the annotations itself.
Below the stack traces.
com.atlassian.util.concurrent.LazyReference$InitializationException: com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
and sometimes only this once, where the REST endpoints will still work:
Exception while processing file, /var/atlassian/application-data/jira/plugins/installed-plugins/de.resolution.apitokenauth.jira-1.0.2-SNAPSHOT.jar
java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at com.atlassian.plugins.rest.module.scanner.AnnotatedClassScanner.getClassReader(AnnotatedClassScanner.java:156)
at com.atlassian.plugins.rest.module.scanner.AnnotatedClassScanner.analyzeClassFile(AnnotatedClassScanner.java:148)
at com.atlassian.plugins.rest.module.scanner.AnnotatedClassScanner.indexJar(AnnotatedClassScanner.java:121)
at com.atlassian.plugins.rest.module.scanner.AnnotatedClassScanner.scan(AnnotatedClassScanner.java:55)
at com.atlassian.plugins.rest.module.OsgiResourceConfig.scanForAnnotatedClasses(OsgiResourceConfig.java:96)
at com.atlassian.plugins.rest.module.OsgiResourceConfig.getClasses(OsgiResourceConfig.java:88)
... 6 filtered
at com.atlassian.plugins.rest.module.RestDelegatingServletFilter.initServletContainer(RestDelegatingServletFilter.java:88)
at com.atlassian.plugins.rest.module.RestDelegatingServletFilter.init(RestDelegatingServletFilter.java:61)
... 1 filtered
at com.atlassian.plugin.servlet.DefaultServletModuleManager$LazyLoadedFilterReference.create(DefaultServletModuleManager.java:516)
at com.atlassian.plugin.servlet.DefaultServletModuleManager$LazyLoadedFilterReference.create(DefaultServletModuleManager.java:503)
at com.atlassian.util.concurrent.LazyReference$Sync.run(LazyReference.java:325)
at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:143)
at com.atlassian.util.concurrent.LazyReference.get(LazyReference.java:112)
at com.atlassian.plugin.servlet.DefaultServletModuleManager.getInstance(DefaultServletModuleManager.java:447)
at com.atlassian.plugin.servlet.DefaultServletModuleManager.getFilter(DefaultServletModuleManager.java:440)
at com.atlassian.plugin.servlet.DefaultServletModuleManager.getFilters(DefaultServletModuleManager.java:300)
at com.atlassian.plugins.rest.module.servlet.DefaultRestServletModuleManager.getFilters(DefaultRestServletModuleManager.java:121)
have you resolved this issue? In case you did not, does your API work when you rename its path? I had very similar exception and struggled for hours when I was lucky and used some ‘forbidden keywords’ in my API path (also it might be blocked by some other plugin). I have not found any list of ‘what not to use in paths’ but renaming it resolved the issue in my case.
Requires Java 8 or higher. Support for Java 9, 10, 11 JPMS modules - the code is compiled with Java 8 but provides a Java 9 compiled module-info.class file. Compatible with Android using Android API level 24 or higher. You may need to delete the module-info when using Android or other Java 8 environments.
Since then I’m using the 4.x version and the problem is gone. If I’d delete the module-info as suggested, it might work with 5.x as well, but that would make it harder to maintain.
Many thanks for asking though Much appreciated. And a good reminder to post a solution, even if one found it him/ herself.
I’m facing this issue. I’ve updated the SDK to the latest version, but atlas-version keeps showing AMPS Version 8.0.2 - Any idea on how to update AMPS version?
Did you update your pom also? I don’t think the atlas-version output reflects what your app will use.
I get 8.0.0 even though some of my projects are referenced to use 8.0.2, see below:
Ok, interesting. Thank you @j.borrmann. I updated the amps version in the pom and as you say, atlas-version keeps showing 8.0.2 but the build uses now 8.0.4 - hope that works now.
Also, I found that the confluence.version property influences this error. I had to change it back to a 6.x version in order to get a package which worked for Confluence 6.x.
Yes, building it against the oldest supported version is always a good idea.
But that won’t always work. Sometimes you need to support both old and new,
for instance Jira 7 vs Jira 8. In order to avoid shipping two versions, you need to use some compatibility library. Using reflection usually only works for simple functionality.
We created a compat library in order to deal with Atlassian moving to io.atlassian.fugue
in Jira 8. Some of the service desk APIs rely on that and you couldn’t have a build supporting both Jira 7 and 8 at the same time without it.
Since everyone arrives there when they have this “ResourceConfig” problem, let me add my solution. For me, it was because I was using the @Path annotation, BUT I hadn’t imported the class at the OSGi level, so the host application believed it was a different class with the same name, and thus, believed no *Resource.java was annotated with @Path. The solution was to add this package to the pom.xml:
<build><plugins><plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>amps-maven-plugin</artifactId>
<version>8.2.1</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Import-Package>
...
javax.ws.rs.core;version="0.0.0",
javax.ws.rs;version="0.0.0",
<!-- While we're at it... -->
com.atlassian.plugins.rest.common.security;version="0.0.0"
I’m also facing this same issue . When I add both javax.ws.rs package within my import-package section of pom.xml file . I’m getting below mentioned error :
java.lang.ArrayIndexOutOfBoundsException: Index 19 out of bounds for length 19
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:579)
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:497)
at aQute.bnd.osgi.Clazz.parseClassFileWithCollector(Clazz.java:486)
at aQute.bnd.osgi.Clazz.parseClassFile(Clazz.java:476)
at aQute.bnd.osgi.Analyzer.analyzeJar(Analyzer.java:2195)
at aQute.bnd.osgi.Analyzer.analyzeBundleClasspath(Analyzer.java:2101)
at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:139)
at aQute.bnd.osgi.Builder.analyze(Builder.java:352)
at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:618)
at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:213)
at org.apache.felix.bundleplugin.ManifestPlugin.getManifest(ManifestPlugin.java:114)
at org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:69)
at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:294)
at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:285)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at org.twdata.maven.mojoexecutor.MojoExecutor.executeMojoImpl(MojoExecutor.java:172)
at org.twdata.maven.mojoexecutor.MojoExecutor$ExecutionEnvironmentM3.executeMojo(MojoExecutor.java:476)
at org.twdata.maven.mojoexecutor.MojoExecutor.executeMojo(MojoExecutor.java:75)
at com.atlassian.maven.plugins.amps.MavenGoals.generateBundleManifest(MavenGoals.java:1553)
at com.atlassian.maven.plugins.amps.osgi.GenerateManifestMojo.execute(GenerateManifestMojo.java:65)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:954)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Much appreciated. And a good reminder to post a solution, even if one found it him/ herself.