[
https://issues.apache.org/jira/browse/ARTEMIS-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Yeats updated ARTEMIS-3596:
--------------------------------
Description:
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,
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.
was:
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 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, 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.
> 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
>
> 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,
> 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)
