activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Alternatives for deprecated setKeyAndTrustManagers in ActiveMQSSLConnectionFactory
Date Thu, 26 Mar 2009 22:48:12 GMT
Just looked at SslTransportFactory.setKeyAndTrustManagers again,  it makes
sense to deprecate because this api used to set the sslcontext for the
factory. It is now changed in line with the use of thread local but the api
for setting the thread local is SSLContext.setCurrentContext.

So the behavior has changed to keep it in line with the use of a thread
local but the intention of setting a context on the factory is depreciated.
I added a @see reference to SSLContext.

2009/3/26 Gary Tully <>

> An ActiveMQ ssl client is just like an other java application that wants to
> use ssl. Configuration is through JSSE.
> The ActiveMQ SSLContext is just a thread specific holder for a regular
> SSLContext, if no context is specified the platform default (from JSSE) will
> be used. The thread specific nature allows different credentials to be used
> in the same JVM. If individual contexts are not required, then configure
> JSSE at the JVM level and ActiveMQ will pick up the default socket factory
> and work with it.
> So you are on the right track, if you want to programmaticly specify the
> JSSE credentials and stores, pass the arguments to an instance of
> SSLContext.
> If you want to remain JMS agnostic, then you should stick to the raw JSSE
> apis.
> What restrictions does: "as our's is an enterprise application." imply?
> And that deprecated of setKeyAndTrustManagers, I will remove that as it is
> a handy method and it no longer sets up shared credentials, it just sets a
> current context using the thread local.
> The alternative is to construct an ActiveMQ SSLContext wrapper and use its
> setters and call getSSLContext or just use raw JSSE SSLContext.
> 2009/3/26 soody <>
>> We want to use SSL in our client that will be sending messages to
>> ActiveMQ.
>> But we can't set the trust stores and key stores using
>> System.setProperty(),
>> as our's is an enterprise application.
>> Are there any ways that I can set the trust and key stores, basically the
>> SSLContext. Currently what we are thinking is that we will be using the
>> SSLContext.setCurrentSslContext(<will create a context using JSSE and dump
>> it here>).
>> Is there any better approach. Also will be great if we can get anything
>> more
>> pluggable, that we can use across multiple JMS providers.
>> Also why is the method setKeyAndTrustManagers  marked as deprecated and
>> what
>> is the workaround for the same.
>> --
>> View this message in context:
>> Sent from the ActiveMQ - User mailing list archive at
> --
> Open Source SOA


Open Source SOA

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message