Scan for jax-rs @Provider in plugin library jars

Description

Summary

From https://ecosystem.atlassian.net/browse/DEVHELP-3139

Currently, Atlassian REST is scanning for classes annotated with @Provider and @Path only plugin jar, but it doesn't scan library jars that are bundled with plugin.

It would be great if it would also scan all jars inside plugin jar, or jars that are specified in MANIFEST in Bundle-ClassPath

Workaround

Explode library jar during build process.

Environment

None

Testing Notes

Add notes...

Activity

Show:
Marek Tokarski
April 16, 2021, 12:31 PM

after your explanation it makes more sense to has that feature request. I’m not sure if we will have capacity to do it, but we can have it in our long term backlog.

Andrew S
April 16, 2021, 5:24 AM
Edited

What will happen if I will not extract dependencies (store them as separate jars), but they contains the same “files” as main plugin jar? How OSGi classloader will behave - my own files (classes) will be used, the one from dependencies or it is unknown?

Great question. I made a small demo project to explore this. Here’s the findings:

  • if two or more of the plugin’s dependencies (or the plugin itself) contain a file with the same name and path (e.g. many Spring JARs contain both spring.handlers and spring.schemas files in their root), then extracting the dependencies means that the first such file found in a dependency will overwrite all the others (including the plugin’s own file) in the final plugin JAR. This can have serious consequences for correctness and maybe even performance (e.g. Spring will make network calls to find XML schemas if it can’t find them on the classpath).

  • if you don’t extract your dependencies (the scenario you’re asking about), then all files of the same name will remain intact and can be loaded all at once by calling ClassLoader#getResources() (which is what the Spring Framework does in order to find all the spring.handlers and spring.schemas files across all the Spring JARs). Calling ClassLoader#getResource() on the other hand seems to favour the file belonging to the plugin, although I’m not sure if this is guaranteed.

Marek Tokarski
April 15, 2021, 7:28 AM

I don’t think we should rely on package to scan “other sources” but that is an implementation detail at the moment.

You are expert of AMPS, but from what I understand extracting compiled dependencies directly into plugin jar is the default behaviour?

What will happen if I will not extract dependencies (store them as separate jars), but they contains the same “files” as main plugin jar? How OSGi classloader will behave - my own files (classes) will be used, the one from dependencies or it is unknown?

My understanding is if you are overriding some files in your final jar, changing the way how dependencies are bundled my fix the “warnings” on the build stage, but you still have the same problem - potential duplicates.

Marek Tokarski
April 14, 2021, 3:04 PM

Based on my experience AMPS extracts plugin dependencies directly into the jar, so they will be scanned and registered by Atlassian REST.

It looks like the “workaround” is the default behaviour, so I’m closing that issue.

Krystian Brazulewicz
November 12, 2019, 1:09 PM

Answer from :

We want to use utility library in our plugins which includes custom exceptions and exception handlers. We’re currently working around this by exploding jar of this library during build process.

Assignee

Unassigned

Reporter

Alexey Belostotsky