Jira DC 10.4 to 10.6 jakarta.json.spi.JsonProvider: Provider org.eclipse.parsson.JsonProviderImpl not found

Jira Development Jira Data Center
1

Hello,

We have a plugin working on Jira DC 10.3.X and we’ve been trying to use it on 10.4 and later but we’ve noticed we would always get an exception when trying to manipulate JSON

java.util.ServiceConfigurationError: jakarta.json.spi.JsonProvider: Provider org.eclipse.parsson.JsonProviderImpl not found
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1219)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1228)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
at jakarta.json.spi.JsonProvider.provider(JsonProvider.java:68)
at jakarta.json.Json.createObjectBuilder(Json.java:275)

It appears that since 10.4.0 Jira is now bundling Eclipse’s parsson 1.1.6 jar and as a side effect our service loader is looking for an implementation package of org.eclipse.parsson
whereas we are bundling glassfish’s jakarta.json 2.0.1.

This doesn’t necessarily look like a big change but it starts to seem weird when factoring in the fact that Jira will not provide parsson (silently ignoring the import package instruction without any DmzResolverHook log)

So before changing our plugin’s dependencies could you confirm that this is indeed the desired behavior and that each plugin should now bundle parsson? Or is there another way we should be dealing with this dependency change in a minor Jira version?

Thanks

2

If anyone is interested the recommendation from Atlassian is to switch to parsson dependency… and you might still face incompatibility issues in specific contexts (EventListener, PluginLifecycle…)

2025-06-10 17:44:00,816+0200 https-openssl-nio-8555-exec-4 ERROR      [o.a.c.c.C.[.[localhost].[/jira].[action]] Servlet.service() for servlet [action] in context with path [/jira] threw exception [Filter execution threw an exception] with root cause
java.util.ServiceConfigurationError: jakarta.json.spi.JsonProvider: org.eclipse.parsson.JsonProviderImpl not a subtype
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
	at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
	at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
	at jakarta.json.spi.JsonProvider.provider(JsonProvider.java:124)
	at jakarta.json.Json.createReader(Json.java:204)
	at com.sodius.oslc.core.internal.provider.json.Utils.readFrom(Utils.java:54)

In which case the solution is to force the usage of the plugin’s class loader:

final var originalClassLoader = Thread.currentThread().getContextClassLoader();
try {
    final var pluginClassloader = this.getClass().getClassLoader();
    Thread.currentThread().setContextClassLoader(pluginClassloader);
    ...
    try (JsonReader reader = Json.createReader(new InputStreamReader(bais, StandardCharsets.UTF_8))) {
    ...
    }
} finally {
    // Restore the original class loader
    Thread.currentThread().setContextClassLoader(originalClassLoader);
}