Dear all, I have the following configuration for the BrokerService object:
The custom implementation of SslContext allows me to reload the truststore when a new certificate is added in the jks file. Everything works fine when I have my clients directly connected to the broker but it mysteriously fails when I add a proxy connector in between. So I'm trying to debug the process when I have the following topology: I started from the */org.apache.activemq.transport.nio.NIOSSLTransportFactory.createSocketFactory()/ *method, within the proxy broker and I see that the */SslContext.getCurrentSslContext()/* always returns null: this is due to the fact that org.apache.activemq.broker.SslContext has two different ssl contexts management: the first one based on static ThreadLocal /current/ variable and the other one based on non-static /sslContext/ variable. Apparently, I can refresh the latter but not the first one. Unfortunately, the /NIOSSLTransportFactory.createSocketFactory()/ uses the /current/ variable: as a result my new certificate is never used in the ssl handshake. Is this analysis correct? Could you explain why it is structured in this way? Is there a way to get around this? Thank you very much, matteo -- View this message in context: http://activemq.2283324.n4.nabble.com/Rfresh-org-apache-activemq-broker-SslContext-from-disk-jks-content-tp4698040.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
