it is a limitation. the thread local allows the different connectors to find the brokers context, so that network connector and discovered transports can find an appropriate context. This makes it simple to configure (broker wide) but difficult to modify and difficult to have per endpoint ssl options.
The connectors and ssl factories need to be be refactored to have their own sslcontext and only delegate to the broker context in the absence of a specialisation. On 22 June 2015 at 13:07, matteor <matteo.ru...@abodata.com> wrote: > 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.
