activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Mittler" <nathan.mitt...@gmail.com>
Subject Re: activemq-cpp and ssl support
Date Tue, 16 Oct 2007 17:19:35 GMT
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message