[
https://issues.apache.org/jira/browse/ARTEMIS-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated ARTEMIS-3596:
------------------------------------
Fix Version/s: 2.19.1
> ServiceLoader.load causing issues in OSGi enviroments.
> ------------------------------------------------------
>
> Key: ARTEMIS-3596
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3596
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: osgi
> Affects Versions: 2.19.0
> Reporter: Ryan Yeats
> Priority: Major
> Fix For: 2.20.0, 2.19.1
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Our system runs Artemis inside of Karaf as an OSGi bundle. Starting with
> version 2.19.0 of Artemis, Artemis fails to start correctly due to an
> exception during the bundle resolution process. The problems happens when the
> artemis-server-osgi bundle is reloaded by the bundle resolution process. The
> bundle starts correctly the first time, but during the resolution process, an
> import Artemis uses is refreshed causing the bundle to be reloaded.
> Consequently, the ServiceLoader.load method is called again by the static
> initializer block in the SSLContextFactoryProvider class. The
> ServiceLoader.load is passed in a class loader is obtained by calling
> Thread.currentThread.getContextClassloader(). The first time the static
> initializer block is executed, the classes DefaultSSLContextFactory and its
> interface, SSLContextFactory, are loaded. However, on reload
> Thread.currentThread.getContextClassloader() returns the original
> DefaultSSLContextFactory which is no long the one corresponding to the class
> loader of the bundle the second time it is started. Resulting in the
> following error message:
> org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactory:
> org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultSSLContextFactory
> not a subtype
> I believe the best way to fix this is to change
> ServiceLoader.load(SSLContextFactory.class,
> Thread.currentThread().getContextClassLoader())
> to
> ServiceLoader.load(SSLContextFactory.class,
> SSLContextFactoryProvider.class.getClassLoader())
> Which for any environment that doesn’t juggle class-loaders like OSGi would
> evaluate to the same class-loader.
> I also noticed several places that ServiceLoader.load(<class>.class) was
> called which should also be changed to pass in the class-loader of the class
> since they would default to the thread context class-loader also.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
