activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tab...@twcny.rr.com>
Subject Re: activemq-cpp and ssl support
Date Tue, 16 Oct 2007 18:43:27 GMT
Hey, that was going to be my suggestion!  :)

Hiram Chirino wrote:
> To make it simpler perhaps you can put the ssl configuration in a file
> and refer to that in the uri...
>
> cf->createConnection("ssl://localhost:12121?conf=./path/to/file.conf");
>
> On 10/16/07, Nathan Mittler <nathan.mittler@gmail.com> wrote:
>   
>>> I know the goal is to use apr for service abstraction.  It would be nice
>>> if someone with more knowledge of it give a shot from configuration
>>> point of view.  I think subversion has support to use either installed
>>> or "embedded" version of it.
>>>
>>> We definitely have need to use apr in the build tree without installing
>>> it first.
>>>       
>> Unfortunately, none of us are experts at the "art" of managing external
>> dependencies with autoconf :(.  We do, however, have a binary dependency on
>> apr in our m4 files.  Perhaps we could change the way our build handles apr
>> to be more like subversion?
>>
>> Regardless, for now I don't see anything wrong with just manually installing
>> apr locally to get your build working with the apr trunk.  It will take a
>> bit to get ssl right anyway and by the time it's there, they might have a
>> release distro of apr that includes ssl.
>>
>>
>>     
>>> From the user perspective, we want all of the SSL configuration
>>>       
>>>> embedded in the connection uri (e.g.
>>>> "ssl://localhost:12121?sslProperty1=yadda").
>>>>         
>>> That came to my mind initially, technically the easiest thing to do.
>>>
>>> The client key and certificate might be different for each connection
>>> and not directly related to connection itself.  The ugly bit is that
>>> you would need to pass paths to local filenames in the uri and often,
>>> in practice, construct them on fly.  Something else might be nicer, but
>>> I don't know what.
>>>
>>> I don't have any strong feelings either way, just what seems right.  Any
>>> good arguments?
>>>       
>> Unfortunately, uri parameters are probably the only pure way to deal with
>> provider-specific parameters.  Otherwise, the user will have to go behind
>> the scenes and make direct calls to the underlying transport, which would
>> get icky.  I'm not sure that passing file paths in the uri is such a bad
>> thing.  The user can always construct the uri with variables.
>>
>> string uri = string("ssl://localhost:12121?sslClientCert=") + clientCert +
>> "...";
>>
>> Alternatively, we might be able to add support for embedding environment
>> variables in the uri string.
>>
>> cf->createConnection("ssl://localhost:12121?sslClientCert=${clientCert}...");
>>
>> That's a little out of scope for this effort, however :).  I would say go
>> ahead and add everything as uri parameters and we can come up with fancy
>> ways of helping users clean up the uri's later.
>>
>>
>> Teemu
>>
>>
>> Regards,
>> Nate
>>
>>     
>
>
>   


Mime
View raw message