Random "ResourceConfig instance does not contain any root resource classes" exceptions in Jira 7 and some early Jira 8 versions

Hi everybody,

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 (https://ecosystem.atlassian.net/browse/ATST-233). 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
	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)

Any comment would be highly appreciated.

1 Like

Hello Johannes,

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.

Hope it helps.

Hi Markéta,

in our case it was not that straightforward, but this dependency: https://github.com/seancfoley/IPAddress
If you look at the notes for the 5.2.0, it states

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 :slight_smile: Much appreciated. And a good reminder to post a solution, even if one found it him/ herself.

Best regards,

1 Like

@j.borrmann There is a known bug in the AMPS maven plugin. https://ecosystem.atlassian.net/browse/AMPS-1509?atlOrigin=eyJpIjoiNTJkZWQ5NDkyMTdhNDc3ZGFiZmNiNTUxNzZlNjRjZWYiLCJwIjoiaiJ9

You can use AMPS 8.0.4 and the problem should be resolved.

I was facing a similar issue with a Confluence Plugin App. Only occured in Confluence 6.x.

Since the issue is not easily reproducible (sometimes it works, sometimes not) I cannot be 100% sure if it is solved in my case.

However after updating the following dependency to 6.1.2, things seem to work again:


Please everybody else facing this issue, share further insights here. Thanks.

Hi Dennis,

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?


ATLAS Version:    8.0.16
ATLAS Home:       /Applications/Atlassian/atlassian-plugin-sdk-8.0.16
ATLAS Scripts:    /Applications/Atlassian/atlassian-plugin-sdk-8.0.16/bin
ATLAS Maven Home: /Applications/Atlassian/atlassian-plugin-sdk-8.0.16/apache-maven-3.5.4
AMPS Version:     8.0.2

Thank you!

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.

<!--        <confluence.version>7.2.0</confluence.version>-->

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.