Robert Greig wrote:
On 26/01/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
It's OK for a broker to depend on explicit configuration, but a client
library is usually used in very different contexts, and at least in
some of
those forcing external configuration is going to cause a lot of troubles.
Likewise, it's very OK to be able to use external configuration (an
XML file
for example) as an *alternative* to the API, but shouldn't be the only
way
to set options like this, I think.
Yes, agree completely.
RG
OK. I feel like I haven't been clear about my intentions wrt the client. Let me
outline what I've gotten written for the client:
1) org.apache.qpid.client.SSLConfiguration class which contains three pieces of
info: keystore file path, keystore password, and cert type (defaults to "SunX509").
2) Modifications to the constructors on org.apache.qpid.client.AMQConnection to
accept an additional SSLConfiguration argument.
3) Changed the logic in org.apache.qpid.client.AMQProtocolHandler to get the
SSLConfiguration from it's parent AMQConnection and call the SSLContextFactory
(from qpid commons) to create a SSLContext to pass to Mina.
So, from a coding perspective the only thing which a developer needs to do to
enable SSL is create an instance of SSLConfiguration with the appropriate
information and then use that instance when creating a AMQConnection instance
directly or via a AMQConnectionFactory.
I still have some cleanup to do with FailoverHandler and write a few tests, but
the basic work is done (I think). I think this satisfies the requirements I've
heard on the list.
--Kevin
