[
https://issues.apache.org/jira/browse/ARTEMIS-3596?focusedWorklogId=695097&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695097
]
ASF GitHub Bot logged work on ARTEMIS-3596:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 13/Dec/21 14:31
Start Date: 13/Dec/21 14:31
Worklog Time Spent: 10m
Work Description: ryeats commented on pull request #3869:
URL: https://github.com/apache/activemq-artemis/pull/3869#issuecomment-992538111
Yes, I understand that is why it took me so long to respond initially. While
I was trying to figure out what was going on I was seeing issues but possibly
not the issues you saw because these didn't seem to be because of my changes.
Then I rebased and my problem now is they are not failing anymore and I didn't
do anything to fix it. When I debug through the code I changed with or without
my change it returns the same class from ServiceLoad.load each time so i don't
have a lot to go on. I was hoping you had an idea since i am going to be going
back through recent commits to see which one fixed the issue we were seeing
otherwise.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 695097)
Time Spent: 2h 10m (was: 2h)
> 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
> Time Spent: 2h 10m
> 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)
