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 18:47:20 GMT
Sounds good to me!

On 10/16/07, Timothy Bish <tabish@twcny.rr.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message