Kevin,
I think what you describe seems good. I am not sure we even need to add
any config as these options can easily be set pragmatically. I would be
inclined to do examples and leave it to the user to decide how to store
the options as config if they want to.
Carl.
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
