The internal structure of NTLMAuthentication is changed and that's why I
changed the serialVersionUid as well. If unchanged, I guess the old
serialized form can still be accepted by the new class, but all new
field will become null/0. After the change, any such deserialization
should throw a exception immediately.
Of course this means if someone really depends on serialization to work
between different versions of JDK, it would be broken. Is there a reason
why this class, child of AuthenticationInfo, child of AuthCacheValue, is
declared Serializable at the beginning?
Thanks
Max
On 08/26/2010 06:57 PM, Michael McMahon wrote:
Why is the serialVersionUid changed in NTLMAuthentication?
Otherwise, the encapsulation of NTLM in the new API looks quite
concise and neat to me? Looks fine.
- Michael
Vincent Ryan wrote:
The SASL component looks good Max.
Michael/Chris: have you any comments on the NTLM changes?
On 25/08/2010 06:23, Weijun Wang wrote:
Ping again.
The webrev is updated:
http://cr.openjdk.java.net/~weijun/6911951/webrev.01/
The CCC is about to be finalized:
http://ccc.sfbay.sun.com/6911951
Thanks
Max
On 04/16/2010 11:12 AM, Weijun Wang wrote:
Vinnie
Please take a review on this webrev:
cr.openjdk.java.net/~weijun/6911951/webrev.00/
I've updated the spec a little by making NTLMv2 as the default
version. It has been supported for a long time and now default with
Windows 7 and Server 2008 R2.
Networking guys, are you OK with the rewrite of NTLMAuthentication?
Thanks
Max
On Jan 4, 2010, at 12:30 PM, weijun.w...@sun.com wrote:
*Change Request ID*: 6911951
*Synopsis*: NTLM should be a supported Java SASL mechanism
=== *Description*
============================================================
The NTLM support currently available for HTTP authentication should
be generalized
and made available as a Java SASL mechanism for use with other
protocols.
