How about something like the following:
String secProviderClass =
System.getProperty("httpclient.security.provider","org.bouncycastle.jce.prov
ider.BouncyCastleProvider");
java.security.Provider = (java.security.Provider)
Class.forName(secProviderClass).newInstance();
Security.addProvider(new
org.bouncycastle.jce.provider.BouncyCastleProvider());
Dennis Cook
BeVocal, Inc.
tel: 650-641-1424
fax: 650-210-9275
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Jeff Dever
Sent: Friday, September 27, 2002 6:24 PM
To: Jakarta Commons Developers List
Subject: Re: [GUMP][httpclient] Build Failure - commons-httpclient
Stefan,
I guess we could fix this by replacing the offending line with:
Security.addProvider(new
org.bouncycastle.jce.provider.BouncyCastleProvider());
So that the BouncyCastle implementation is used instead, but that should not
be forced on us. At the moment Adrian is the only one using
NTLM authentication and he wants the SunJCE provider.
I do not know how to choose one dynamicly at compile time in java (in C++
I'd check a #define and do a conditional compilation). Perhaps a
Any suggestions from the java build gurus on how to accomplish this?
If this is not feasable, can we get the SunJCE added to the GUMP build
environment?
>
> No, in the Gump descriptor (I've already done so), but a problem
> remains for me (Gump uses bouncycastle's JCE implementation):
>
> [javac]
/home/bodewig/dev/gump/jakarta-commons/httpclient/src/java/org/apache/common
s/httpclient/NTLM.java:91: cannot resolve symbol
> [javac] symbol : class SunJCE
> [javac] location: package provider
> [javac] Security.addProvider(new
com.sun.crypto.provider.SunJCE());
> [javac]
^
> [javac] 1 error
>
> can you make that independent of the Sun implementation?
>
>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
