Kevin Smith wrote:
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
I also wanted to mention that the code changes for the broker and commons are
attached as a patch to the JIRA issue, if anyone wants to take a look at that.
--Kevin
