I think when SPNEGO is specified to be the default mechanism for JGSS
(as the property name implies), it should be up to the SPNEGO
implementation to specify what its default concrete mechanism should be.
I think your new constant DEFAULT_MECH_OID2 should conceptually at the
SPNEGO mech provi
Changeset: da9d0283a496
Author:valeriep
Date: 2009-03-03 19:50 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da9d0283a496
6812738: SSL stress test with GF leads to 32 bit max process size in less than
5 minutes with PCKS11 provider
Summary: Removed finalize() and add more e
Changeset: 850869f70213
Author:mcimadamore
Date: 2009-03-05 17:24 +
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/850869f70213
6467183: javac fails to raise unchecked warning on cast of parameterized
generic subclass
Summary: cleanup code for generating unchecked cast w
> I have no choice but (c). Personally, I really think SNI is becoming a
> have-to-have feature with the grow of virtualization computing.
Here's a webrev which enables SNI on the client end, whenever not
using SSL 2 Hello, and when system property
"sun.security.ssl.disableHelloExtensions" is unse
"sun.security.jgss.mechanism", it is a undocumented property, right? I
think it is hard to explain why SPNEGO is request, but KRB5 given, it
is not the expected behavior. Why not thrown a GSSException?
Andrew
Weijun Wang wrote:
Hi Andrew or Valerie
Please take a review at this bug fix:
h
