OSGi dependencies do not properly imported since Jira 8.5.2

Jira Development Jira Server
1

We are using an OSGi dependency in our app declared with compile scope as follow:

<dependency>
   <groupId>com.google.guava</groupId>
   <artifactId>guava</artifactId>
   <version>10.0.1</version>
   <scope>compile</scope>
</dependency>

Until Jira 8.5.1, this version were getting imported as expected.

But from Jira 8.5.2, something has changed around class loading, since the Guava version declared by Jira is used (copied from “OSGi” page under “Import-Package”):

com.google.common.base version: [26.0.0,26.0.0]
Provided by System Bundle

This causes errors at runtime.

It seems that other vendors also face errors recently that can be caused by the same root cause: Random "ResourceConfig instance does not contain any root resource classes" exceptions in Jira 7 and some early Jira 8 versions - #4 by dennis.fischer

That particular problem is rooted here: [AMPS-1509] - Ecosystem Jira
We updated AMPS to 8.0.4, but the problem is still there.

Have you experienced similar problems recently? It seems to be a general issue and may affect many users/app vendors.

1 Like
2

I’m not sure if this is related, but compile scope dependencies are usually bundled with your plugin.

If you want to get dependency from osgi, it should be in provided scope, and bnd will pick it up for import-package during build process. Unless you specify import-package for these dependencies explicitly.

3

Also, this is very helpful for getting the right versions of provided dependencies Jira Server is making declaring dependencies easier - Atlassian Developer Blog

4

@gergely.juhasz The linked thread and AMPS bug is unrelated to your problem. Is there a specific reason why you want to use the very old guava 10.0.1? I recommend upgrading to 26.0.0 and use it as provided dependency.

In your Import-Package definition you can try to use !com.google.guava.* such that the dependency on your classpath is used and not imported via OSGi.

5

@dennis.fischer We simply must use that Guava version, because there are scripts using that particular version written for our app and we cannot control those scripts. We must guarantee that it is Guava 10.0.1 available for all our code.

We will try to disable importing the problematic package, thanks for the hint. (In fact, we experimented with that yesterday with no luck, but now giving a second try.)

6

Yes, we are aware of these. And we believe we are working correctly with Maven dependencies and OSGi bundles. Our code has been working correctly for several years. It started to break only in the most recent Jira version (8.5.2 and 8.6.0) and it feels that Atlassian changed something under the hood.

7

Folks, It reported this to Atlassian as: Jira Service Management

If anyone is affected by problems that are related to OSGi and classloading and are present in Jira 8.5.2 and 8.6.0, but the problem is not present in 8.5.1, drop me a message and I can add you to that ticket.

8

Workaround:
Replacing atlassian-plugins-osgi-5.3.3.jar to atlassian-plugins-osgi-5.2.2.jar under Jira 8.5.2 eliminated the problem after reinstalling the app!

See the details in the comments at: Jira Service Management

2 Likes
9

@nmansilla I really hate cross-posting, but this needs to get attention ASAP. Are you guys aware that there is a killer bug in how recent Jira versions (8.5.2 and 8.6.0) wire OSGi bundles?

It took us multiple days around Xmas :frowning: to find the root cause and reported this to Atlassian: Jira Service Management

The problem is also (very likely) present in modern Confluence versions, and is affecting several app vendors.
As it came out in the festive season, I’d tend to think that it will affect even more vendors and ultimately even more end-users, who were not working in the last 2 weeks and will be surprised when they come back.

Is there any chance that you resolve that as a priority issue?

1 Like
10

Yes, please- we’ve seen problems in a few environments and only in 8.5.2 and 8.6.0 but I’m under the impression that the Atlassian Universal Pluginmanager update from 4.0.8 to 4.0.10 solved it. At least 4.0.8 is not visible in the marketplace anymore. Still, it would be great if you can add me to the ticket.

11

@j.borrmann Your email address is?

13

@j.borrmann Added you to the ticket!

1 Like
14

Please clarify, does this affect every custom add-on running on Jira 8.5.2?

15

@alj Not all apps are affected, but there can be many. It is difficult to tell, because I cannot know which apps rely on low-level OSGi wiring, Jira’s own OSGi bundles and class loading. If you give me your email address, I can add you to that ticket.

16

I PM’d you my email. Thanks!

17

@aron.gombas could you please add me to DEVHELP-4024? andreas dot ebert at communardo dot de
Thanks.

18

@AndreasEbert I added you!

19

(Sorry for cross-posting here, but it may be useful also for this thread.)

FYI I wrote a quick summary about this story for our end-users, including a high-level summary of the root cause, the symptom (which is specific to our app), but most importantly the potential workarounds and our advice what to do. (You can eventually use parts of it to communicate your case with your end-users.)

See: Why aren't Midori apps available for Jira 8.6 yet (as of 6 Jan 2020)? | Midori

1 Like
20

We’ve reached out to some folks on the Jira Server team, and will ask them to chime in as soon as possible.

21

Okay. This is an issue that the Jira Server team is aware of: [JRASERVER-70445] Some plugins' dependency versions get unexpectedly overridden - Create and track feature requests for Atlassian products.

Now, there are a lot of internal (Atlassian-only) comments on that ticket that you won’t be able to see. It appears that they have identified root cause.

I’ll request that they make some public comments (either on the ticket, and/or this thread).