Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Date: Thu, 14 Aug 2003 23:01:11 +1000
Subject: Re: NTLM class
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Adrian Sutton <adrian@intencha.com>
To: "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: 
 <OFF753E9D4.D9518EFF-ONC1256D82.00402724-C1256D82.00448BF2@de.ibm.com>
Message-Id: <613EB6C0-CE57-11D7-857E-000393016056@intencha.com>

> I believe these initializations should be removed completely.
> They can never have been more than a convenience in the
> first place.

You are correct that they were to avoid having to avoid playing with 
the java.security file.  I originally wrote the NTLM support with our 
applet in mind which absolutely must install without any active effort 
on the users part so editing the java.security file is right out.  On a 
side note it is nigh on impossible to use JCE from an applet anyway 
since it closes the jar file which later causes the class loader to 
crash, so we actually have a modified HttpClient that uses a standalone 
DES encryption class instead of JCE.

My only concern with removing the code now is that we are so close to a 
release and this is a change that clearly does have some fallout even 
if we anticipate it to be very small.

> The only negative impact I can think of is for those that
> got SSL running without registering the JSSE provider
> properly. These people would have the choice between
> adding a line to their java.security file, or putting the three
> lines of initialization code in their own program.
> The first choice is better for creating an installation on a
> particular machine, the second is better for packaging a
> program with HTTP client and JSSE that has to run on
> a variety of host JVMs. But those who care about this
> difference will have done the appropriate thing anyway
> and won't notice any change at all.

We will need to make this *very* clear in the documentation as the 
error message you get when the JCE provider isn't registered properly 
is extremely misleading and gives no hint that the java.security file 
should be edited.

> regards,
>   Roland

If anyone does have any objections or know of likely problems removing 
this code would cause please do speak up now.

Regards,

Adrian Sutton.

----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com