activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: activemq-cpp and ssl support
Date Tue, 16 Oct 2007 17:46:14 GMT
To make it simpler perhaps you can put the ssl configuration in a file
and refer to that in the uri...


On 10/16/07, Nathan Mittler <> 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



View raw message