If I recall correctly, "initialized" and checkInitialized() method are
meant to prevent unauthorized creation of Provider object either through
inheritance or deserialization. Thus, they should not be removed unless
we are sure that the original issue are no longer of concern.
Thanks,
Valer
Another way to avoid hand-coded SPNEGO here would be to use SSPI for SPNEGO.
That could negotiate Kerberos or NTLM, but I do believe there's a way to tell
it to only negotiate Kerberos -- I'm not terribly familiar with the details,
but I'm pretty sure that Martin Rex's GSS->SSPI shim handles this.
On Wed, Dec 12, 2018 at 11:48:26AM -0800, Valerie Peng wrote:
> If anyone is still reviewing this and need more time, please let me know
> soon. Otherwise, I will proceed with integration this afternoon.
One comment:
- checkInitialized() in java.security.Provider seems pointless -- initialized
Hi Max,
On 12/13/2018 10:35 AM, Weijun Wang wrote:
Hi Roger,
I didn't run "make docs-javadoc" but I have a script that directly call the
javadoc command. While the comment still exists in the output HTML, it is still a
comment, and therefore invisible on the page.
True, but the comments are
Hi Roger,
I didn't run "make docs-javadoc" but I have a script that directly call the
javadoc command. While the comment still exists in the output HTML, it is still
a comment, and therefore invisible on the page.
Can {@link} be used to link to a URL? I only know about using it to link to
cla
Hi,
Thanks for converting the package doc.
There is XML commented text in the package-info.java that should be removed.
It would show up in the javadoc.
And there are links that can now use {@link}.
It probably worth % make docs-javadoc and checking the result in
images/docs/api.
Thanks, R
On 2018-12-13 14:06, Daniel Fuchs wrote:
Looks good Claes!
Thanks!
I eyeballed the rest of the patch and found
nothing wrong - but with a patch this size
it would be easy to miss something.
Yes, I've gone through it a couple of times now
to be sure.
Were you able to measure any improveme
Looks good Claes!
I eyeballed the rest of the patch and found
nothing wrong - but with a patch this size
it would be easy to miss something.
Were you able to measure any improvement after
patching?
best regards,
-- daniel
On 12/12/2018 17:06, Claes Redestad wrote:
On 2018-12-12 17:54, Dani
Thanks Erik!
Pushed.
Best regards,
Goetz
> -Original Message-
> From: serviceability-dev On
> Behalf Of Erik Gahlin
> Sent: Thursday, December 13, 2018 12:34 PM
> To: security-dev@openjdk.java.net; serviceability-dev (serviceability-
> d...@openjdk.java.net)
> Subject: Re: 8215534: [t
Looks good.
Erik
Hi,
These tests lack @requires vm.hasJFR, thus they are failing on AIX.
http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/
Please review.
I will push this to jdk12 as it is a testbug if I miss the RDP deadline.
Best regards,
Goetz.
Thanks Sundar!
Best regards
Goetz
> -Original Message-
> From: Sundararajan Athijegannathan
>
> Sent: Thursday, December 13, 2018 9:47 AM
> To: Lindenmaier, Goetz
> Cc: security-dev@openjdk.java.net; serviceability-dev (serviceability-
> d...@openjdk.java.net)
> Subject: Re: 8215534:
Looks good.
PS. I just checked that there are other tests with the same requires clause.
-Sundar
On 13/12/18, 1:20 PM, Lindenmaier, Goetz wrote:
Hi,
These tests lack @requires vm.hasJFR, thus they are failing on AIX.
http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/
Please revi
12 matches
Mail list logo