commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: [GUMP][httpclient] Build Failure - commons-httpclient
Date Mon, 30 Sep 2002 06:35:48 GMT
On Fri, 27 Sep 2002, Jeff Dever <jsdever@sympatico.ca> wrote:

> I guess we could fix this by replacing the offending line with:
> 
>     Security.addProvider(new
>     org.bouncycastle.jce.provider.BouncyCastleProvider());

In German I'd call this "den Teufel mit dem Beelzebub austreiben",
don't know whether there's an English expression for replacing one bad
with another bad. 8-)

That way you'd tie your users to bouncycastle's provider.

I'm not a JCE expert either (your patch has fixed building httpclient
on my box, BTW).  There already is a way to define which provider a
user wants to use, namely
<http://java.sun.com/products/jce/doc/guide/HowToImplAProvider.html#Step%205d>
which involves editing a file (and is a static choice).

If the user doesn't set that property, you may simply want to try to
load an implementation and register SunJCE as a fallback if that
fails, dunno.

> If this is not feasable, can we get the SunJCE added to the GUMP
> build environment?

The same way we get any projects into Gump, there would be no magic
involved.  I think the reason why Sam originally decided to use
Bouncycastle's provider was to catch situations like the one at hand,
your code hardcoded SunJCE as the provider of a pluggable API when it
really isn't any reason to do (there'd be a reason if SunJCE was the
only provider for a given algorithm for example).

Export limitations may have been a reason, too, but I'm not sure. It
could have been a reason for me (being citizen of a country who's
government has just "poisoned" the political climate with the USA ;-)

Stefan

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message