hg: jdk8/tl/jdk: 8025140: TEST_BUG: java/util/logging/Logger/getGlobal tests fail due to timeout

Changeset: 76619d71a7c5 Author:dfuchs Date: 2013-09-25 09:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76619d71a7c5 8025140: TEST_BUG: java/util/logging/Logger/getGlobal tests fail due to timeout Summary: Arbitrary timeouts in the tests @run lines where too agressive for

Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl

On 10/1/13 3:09 PM, Seán Coffey wrote: Since I'm only creating a dummy socketImpl to test the classcastexception, no real networking stack is in place here. I'm catching the NPE that would be thrown from the native Java_java_net_TwoStacksPlainSocketImpl_socketAccept function since the underlying

Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl

;re pointing at FileDescriptor Objs, we should be ok. Daniel Fuchs has pointed out another issue. Null delegate being passed into impl.accept if dealing with a custom socketImpl! It should just be impl.accept(s); I'll get this corrected and tested. Thanks for pointers. Sean. On 20/09/13 10:20, Dmitry Sa

Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl

On 10/1/13 4:50 PM, Seán Coffey wrote: On 01/10/2013 14:51, Daniel Fuchs wrote: On 10/1/13 3:09 PM, Seán Coffey wrote: Since I'm only creating a dummy socketImpl to test the classcastexception, no real networking stack is in place here. I'm catching the NPE that would be throw

hg: jdk8/tl/jaxp: 8025745: Clarify API documentation of JAXP factories.

Changeset: f031b2fe21cd Author:dfuchs Date: 2013-10-04 19:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f031b2fe21cd 8025745: Clarify API documentation of JAXP factories. Summary: Clarifies usage of ServiceLoader in JAXP factories. Reviewed-by: alanb, joehw, psandoz ! s

hg: jdk8/tl/jdk: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources.

Changeset: 9f8bfdd99129 Author:dfuchs Date: 2013-10-14 10:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f8bfdd99129 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. Reviewed-by: alanb, psandoz, mchung ! src/s

hg: jdk8/tl/jdk: 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup")

Changeset: 2c16140fb515 Author:dfuchs Date: 2013-10-15 13:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c16140fb515 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Summary: The test 'threadGroup.getParent() =

hg: jdk8/tl/jdk: 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger

Changeset: 445667b19e32 Author:dfuchs Date: 2013-10-16 17:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445667b19e32 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger Reviewed-by: psandoz, mchung, alanb, chegar ! src/share/classes/sun/font/FontUtiliti

hg: jdk8/tl/jdk: 8013839: Enhance Logger API for handling of resource bundles; ...

Changeset: 2ef43f3a901c Author:dfuchs Date: 2013-10-16 20:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ef43f3a901c 8013839: Enhance Logger API for handling of resource bundles 4814565: (rb) add method to get basename from a ResourceBundle Summary: adds Logger.setResourc

hg: jdk8/tl/jdk: 8016344: (props) Properties.storeToXML behaviour has changed from JDK 6 to 7

Changeset: 567d47fd3fe2 Author:dfuchs Date: 2013-10-21 11:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/567d47fd3fe2 8016344: (props) Properties.storeToXML behaviour has changed from JDK 6 to 7 Summary: When storing Properties to XML only locally defined properties must b

hg: jdk8/tl/jdk: 8026499: Root Logger level can be reset unexpectedly

Changeset: c81125493ca6 Author:dfuchs Date: 2013-10-21 12:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c81125493ca6 8026499: Root Logger level can be reset unexpectedly Summary: This fix prevents the logger's level to be re-initialized if it has already been initialized

hg: jdk8/tl/jdk: 8026863: regression in anonymous Logger.setParent method

Changeset: af4dd45bc7f7 Author:dfuchs Date: 2013-10-28 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af4dd45bc7f7 8026863: regression in anonymous Logger.setParent method Summary: restore behaviour of setParent in anonymous logger and clarifies the spec with respect t

hg: jdk8/tl/jdk: 8026952: Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id

Changeset: 30a3aefc4084 Author:dfuchs Date: 2013-11-13 10:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30a3aefc4084 8026952: Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id Summary: Trivial: change @bug 8023163 into @bug

hg: jdk8/tl/jdk: 8028185: XMLFormatter.format emits incorrect year

Changeset: 67d742c75971 Author:dfuchs Date: 2013-11-19 20:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67d742c75971 8028185: XMLFormatter.format emits incorrect year Summary: Fixes a regression where the year in the date was increased by 1900. Reviewed-by: alanb, mchung

hg: jdk8/tl/jdk: 8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10

Changeset: 059530c5ae9a Author:dfuchs Date: 2013-11-19 22:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/059530c5ae9a 8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10 Summary: this test has been seen failing on Solaris 10, presumably because it was

Re: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails intermittently

Hi Tristan, I believe you should also declare the 'error' flag as well as the 'clientCtx' variable volatile since they are set by a thread and read by another. best regards, -- daniel On 11/20/13 5:59 AM, Tristan Yan wrote: /Hi All/ /I am working on https://bugs.openjdk.java.net/browse/JDK-7

Re: 答复: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails intermittently

impleSSLContext(System.getProperty("test.src")).get(); best regards, -- daniel http://cr.openjdk.java.net/~ewang/tristan/JDK-703/webrev.00/ I'm appreciated Chris be my sponsor for this. Thank you. Tristan -邮件原件- 发件人: Chris Hegarty 发送时间: Wednesday, November 20,

Re: 答复: 答复: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails intermittently

On 11/20/13 1:32 PM, Tristan Yan wrote: Oops, I must have bumped my head. Thanks for point this out. http://cr.openjdk.java.net/~ewang/tristan/JDK-703/webrev.00/ Tristan Looks good! -- daniel -邮件原件- 发件人: Daniel Fuchs 发送时间: Wednesday, November 20, 2013 8:12 PM 收件人: Tristan Yan

Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

On 11/29/13 5:19 PM, Alan Bateman wrote: On 29/11/2013 14:21, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8025211 an intermittent f

Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

the errant test machine with consistent success. regards Mark On 29/11/2013 16:41, Daniel Fuchs wrote: On 11/29/13 5:19 PM, Alan Bateman wrote: On 29/11/2013 14:21, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which ad

hg: jdk8/tl/jdk: 8029281: Synchronization issues in Logger and LogManager

Changeset: 9f624e115c6b Author:dfuchs Date: 2013-12-04 01:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f624e115c6b 8029281: Synchronization issues in Logger and LogManager Summary: Fixes several race conditions in logging which have been at the root cause of intermitte

hg: jdk8/tl/jdk: 8030850: Setting .level=FINEST in logging configuration file doesn't work

Changeset: d77a1c9fd5b8 Author:dfuchs Date: 2013-12-22 11:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d77a1c9fd5b8 8030850: Setting .level=FINEST in logging configuration file doesn't work Summary: setLevel(INFO) was called too early on root logger, causing the value f

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

Hi Paul, I looked at -management and the changes there look good. There is just some two spaces vs four space formatting in line 99

Re: RFR: 8043118: update test/java/net/URLPermission/nstest/lookup.sh to use explicit @build target

Hi Michael, On 5/14/14 1:11 PM, Michael McMahon wrote: On 14/05/14 11:39, Alan Bateman wrote: On 14/05/2014 11:35, Michael McMahon wrote: Okay. I just updated my jtreg and the test passes with the wildcard. I'm not sure why it was changed to use the wildcard, but there doesn't seem to be any p

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

On 30/09/14 17:31, Alan Bateman wrote: On 30/09/2014 08:21, Mark Sheppard wrote: Hi Please oblige and review the following small change to test test/java/net/InetAddress/IPv4Formats.java --- a/test/java/net/InetAddress/IPv4Formats.javaTue Sep 30 13:25:04 2014 +0100 +++ b/test/java/net/

Re: RFR [9] 8065072: sun/net/www/http/HttpClient/StreamingRetry.java failed intermittently

Hi Chris, These changes look reasonable to me. best regards, -- daniel On 25/11/14 16:45, Chris Hegarty wrote: This test has been failing intermittently since I updated it recently to cover another similar issue. The test shares a ServerSocket instance across two threads, and as such it sho

Re: RFR 8080486: JNI exception pending in jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c

Hi Vyom, I'm not a net/JNI expert but what you are proposing looks good to me too. Ivan has already given his assent. Unless I hear objections - or comments from other reviewers, I will sponsor this change and push it for you (I'll wait for Monday). best regards, -- daniel On 02/09/15 15:55,

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

Hi Vyom, I will sponsor that and push it for you. best regards, -- daniel On 07/09/15 18:52, Alan Bateman wrote: On 07/09/2015 14:08, Vyom Tewari wrote: Hi All, Please find the latest diff, which contains the latest fix. http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/ I thin

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

Oh - sorry - I hadn't seen Mark question. I will wait until those are resolved... On 07/09/15 19:24, Daniel Fuchs wrote: Hi Vyom, I will sponsor that and push it for you. best regards, -- daniel On 07/09/15 18:52, Alan Bateman wrote: On 07/09/2015 14:08, Vyom Tewari wrote: H

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

On 09/09/15 17:54, Mark Sheppard wrote: Hi Vyom, yes, I believe the consensus is to proceed with the changes. OK - I will be pushing them then. best regards, -- daniel regards Mark On 09/09/2015 16:23, Vyom Tewari wrote: Hi Mark, Is it OK to go ahead with the patch as it is, or you

Re: RFR 8073542 : File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c

Hi Vyom, I will sponsor your change and push the fix for you. I'll sync up with Rob to check that we don't step on each other's toes. best regards, -- daniel On 16/09/15 16:03, Chris Hegarty wrote: The changes look good to me Vyom. -Chris. On 16/09/15 10:08, Vyom Tewari wrote: Hi All, Ple

RFR 8151281: Module java.httpclient could use System.Logger instead of PlatformLogger

Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8151281 8151281: Module java.httpclient could use System.Logger instead of PlatformLogger http://cr.openjdk.java.net/~dfuchs/webrev_8151281/webrev.00/ best regards, -- daniel

Re: RFR 8151281: Module java.httpclient could use System.Logger instead of PlatformLogger

Hi Mandy, On 06/03/16 00:01, Mandy Chung wrote: Hi Daniel, On Mar 4, 2016, at 8:05 AM, Daniel Fuchs wrote: Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8151281 8151281: Module java.httpclient could use System.Logger instead of PlatformLogger http

Re: RFR 8151281: Module java.httpclient could use System.Logger instead of PlatformLogger

On 15/03/16 06:35, Mandy Chung wrote: It’s a nice trick. Perhaps define a new internal class that implements System.Logger with default methods. Any platform classes want itself to be skipped will extend that new internal class? I thought the purpose here was to avoid using internal stuff r

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

Hi Vyom, This looks strange to me: 268 if(!this.methods.isEmpty() && that.methods.isEmpty()) 269 return true; 270 if(this.methods.isEmpty() && !that.methods.isEmpty()) 271 return false; 272 if(this.methods.isEmpty() && that.methods.isEmpty())

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

- but I'm a bit concerned that the previous mistake was not caught that by any test. Could you add a test that fails with you previous fix but passes with the new one? best regards, -- daniel Thanks, Vyom On Sunday 12 June 2016 02:04 PM, Daniel Fuchs wrote: Hi Vyom, This looks strange t

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

Thanks Vyom, Looks good to me. See if you can get someone more experienced in the area to give a thumb up too :-) best regards, -- daniel Thanks, Vyom On Friday 17 June 2016 04:57 PM, Daniel Fuchs wrote: On 17/06/16 09:21, Vyom Tewari wrote: Hi All, Please find the new webre

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

s. Roger On 6/17/2016 8:42 AM, Daniel Fuchs wrote: On 17/06/16 13:25, Vyom Tewari wrote: Hi Daniel, thanks for review please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8071660/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8071660/webrev0.2/index.html>) . I

Re: RFR 8022580: sun.net.ftp.impl.FtpClient.nameList(String path) handle "null" incorrectly

Hi Svetlana, Have you thought of using a CountDownLatch (or some other synchronization mechanism like e.g. Semaphore) to wait for the server to be ready instead of: 55 int port = 0; 56 while (port == 0) { 57 Thread.sleep(500); 58 por

Re: RFR 8022580: sun.net.ftp.impl.FtpClient.nameList(String path) handle "null" incorrectly

best regards, -- daniel Thank you, Svetlana On 12.07.2016 17:25, Chris Hegarty wrote: Svetlana, <http://cr.openjdk.java.net/%7Esnikandrova/8022580/webrev.03/> The source code changes look fine. On the test... On 11 Jul 2016, at 14:20, Daniel Fuchs wrote: Hi Svetlana, Have yo

Re: RFR [9] 8078568 java/net/URLPermission/URLTest.java fails intermittently with BindException

Hi, Looks good to me Chris. The only thing I noticed is this: -if (! (e instanceof SecurityException) && -!(e.getCause() instanceof SecurityException) || -!exceptionExpected) -{ -System.out.println ("FAIL")

Re: RFR [9] 8078568 java/net/URLPermission/URLTest.java fails intermittently with BindException

On 21/07/16 15:20, Chris Hegarty wrote: The new version does not check that e is an instance of SecurityExcption. I'm also a bit surprised to see that the test expects the SecurityException to be wrapped. The SE is expected to be wrapped because of the use of getResponseCode(), as opposed to ge

Re: RFR 8161291: Serialization Tests for URLPermission is failing

Hi Vyom, It would be helpful in the future to include a link to the JBS issue in your request for review. 464 //The colon separator need to be present even if the request headers list is empty I would suggest the comment to be a little more precise: // The colon separator is option

Re: RFR (XS): 8162819: fix minor Javadoc issues and remove warnings in java.net.Socket and java.net.Inet*Address

On 31/07/16 22:47, Langer, Christoph wrote: Hi, please review these small fixes for Javadoc issues and removal of warnings. Bug: https://bugs.openjdk.java.net/browse/JDK-8162819 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8162819.1/ Hi Christoph, The Javadoc changes look good to

Re: RFR (XS): 8162819: fix minor Javadoc issues and remove warnings in java.net.Socket and java.net.Inet*Address

Hi Christoph, On 01/08/16 10:43, Langer, Christoph wrote: Hi Daniel, the warning is shown by my Eclipse IDE, javac -Xlint does not warn about unused methods, I think. So, then the tag @SuppressWarnings("unused") should probably not be used? Or what's the official OpenJDK standard for this ty

Re: RFR 8146602: jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java test fails with NullPointerException

+1 -- daniel On 16/08/16 16:35, Svetlana Nikandrova wrote: Hello, please review this test update. Test do not consider that exception could happen while variable "server" is not initialized yet. As a result log shows NPE instead of the real exception which is irrecoverably lost. I added check

Re: JDK 9 RFR of JDK-8164545: Mark java/net/URLPermission/nstest/lookup.sh as intermittently failing

On 29/08/16 02:17, Amy Lu wrote: Please review. Looks good to me Amy, best regards, -- daniel Thanks, Amy On 8/22/16 4:37 PM, Amy Lu wrote: java/net/URLPermission/nstest/lookup.sh This test is known to fail intermittently (JDK-8156504), this patch is to mark the test accordingly with ke

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

On 15/09/16 08:53, Chris Hegarty wrote: Anyway, as a free port is used, there are free-port issues. Please consider to make the enhancement in the fix. Otherwise, you cannot avoid the intermittent failure for this test case in the current testing environment. +1. Please remove any use of t

Re: RFR 8085575_8130657, misc fixes for a few of java.net intermittent failures

Hi Felix, InheritHandle.java: 79 } finally { 80 try { 81 ss.close(); 82 } catch (IOException e) { 83 e.printStackTrace(); 84 } 85 } Is finally the right construct here? It seems to me that you're c

Re: RFR 8085575_8130657, misc fixes for a few of java.net intermittent failures

/~xiaofeya/8085575_8130657/webrev.01/ Thanks, Felix On 26 Sep 2016, at 5:29 PM, Daniel Fuchs wrote: Hi Felix, InheritHandle.java: 79 } finally { 80 try { 81 ss.close(); 82 } catch (IOException e) { 83 e.printStackTrace(); 84

Re: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty

Hi Vyom, So if I understand well, the class level API documentation allowed for the colon to be either omitted or present: 121 * 122 * The colon separator need not be present if the request headers list is empty. but the getActions() javadoc indicated that the colon would be omitted if t

Re: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty

On 06/10/16 11:46, Vyom Tewari wrote: On Thursday 06 October 2016 03:04 PM, Daniel Fuchs wrote: Hi Vyom, So if I understand well, the class level API documentation allowed for the colon to be either omitted or present: 121 * 122 * The colon separator need not be present if the request

RFR: 8157965 update httpserver logging to use java.lang.System.Logger

Hi, Please find below a patch that updates jdk.httpserver to use System.Logger. As a result jdk.httpserver no longer requires java.logging. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8157965/webrev.00 issue: https://bugs.openjdk.java.net/browse/JDK-8157965 best regards, -- daniel

Re: RFR: 8157965 update httpserver logging to use java.lang.System.Logger

Roger On 10/19/2016 10:52 AM, Daniel Fuchs wrote: Hi, Please find below a patch that updates jdk.httpserver to use System.Logger. As a result jdk.httpserver no longer requires java.logging. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8157965/webrev.00 issue: https://bugs.openjdk.java.net

Re: RFR(s): 8169002: [TESTBUG] Several java/net/httpclient have undeclared dependency on java.logging module

Hi Roger, On 01/11/16 17:21, Roger Riggs wrote: Hi Sergei, I think it would be preferable to convert the tests to use System.getLogger. Is that possible? Some of the tests want to configure the logging, rather than simply produce traces - so they will need java.logging to do that: 670

Re: RFR(s): 8169002: [TESTBUG] Several java/net/httpclient have undeclared dependency on java.logging module

aniel $.02, Roger On 11/1/2016 1:53 PM, Daniel Fuchs wrote: Hi Roger, On 01/11/16 17:21, Roger Riggs wrote: Hi Sergei, I think it would be preferable to convert the tests to use System.getLogger. Is that possible? Some of the tests want to configure the logging, rather than simply produce t

Re: RFR 8156504/9, java/net/URLPermission/nstest/lookup.sh fails intermittently

On 02/11/16 11:18, Chris Hegarty wrote: Thanks for doing this Felix. I have some comments about the style and the use of AccessControlContext. Rather than list them I put an alternative version at the following location, please take a look. http://cr.openjdk.java.net/~chegar/8156504_alt/ No

RFR: 8169068: Add a new method: java.net.Authenticator.getDefault()

Hi, Please find below a patch for: RFR: 8169068: Add a new method: java.net.Authenticator.getDefault() https://bugs.openjdk.java.net/browse/JDK-8169068 The method implementation itself is trivial. The API documentation is derived from that of Authenticator::setDefault The method checks for the

Re: RFR(s): 8169196: [TESTBUG] Three tests from sun/net/www have undeclared dependencies

Hi Sergey, Great to get rid of yet another shell script. The change looks good in general - except for NoNTLM.java: I don't think the test should have @modules jdk.security.auth as the test is precisely supposed to be able to run without it (+ lines 218-223 are probably obsolete and I suspect t

Re: RFR: 8169068: Add a new method: java.net.Authenticator.getDefault()

Hi Chris, Thanks a lot for the feedback. Here is a new webrev incorporating your comments: http://cr.openjdk.java.net/~dfuchs/webrev_8169068/webrev.01 -- daniel On 03/11/16 14:40, Chris Hegarty wrote: Daniel, On 03/11/16 10:20, Daniel Fuchs wrote: Hi, Please find below a patch for: RFR

Re: RFR(s): 8169196: [TESTBUG] Three tests from sun/net/www have undeclared dependencies

Hi Sergey, Yes - sorry - I misunderstood the purpose of the NoNTLM test. The test is supposed to run *only* when NTLM *is not* supported. When NTLM is supported, it is supposed to return without doing anything. Now as it happens, NTLM is supported by default in java.base. The only case where NT

Re: RFR(s): 8169196: [TESTBUG] Three tests from sun/net/www have undeclared dependencies

Hi Sergey, This looks good now - except for line 223: 221 Field ntlmSupportedField = ntlmProxyClass.getDeclaredField("supported"); 222 ntlmSupportedField.setAccessible(true); 223 if (Boolean.TRUE.equals(ntlmSupportedField.getBoolean(ntlmProxyClass))) {

Re: RFR(s): 8169196: [TESTBUG] Three tests from sun/net/www have undeclared dependencies

On 09/11/16 08:57, Sergei Kovalev wrote: Hi Daniel, Thank you for feedback. Fixed and verified locally. http://cr.openjdk.java.net/~skovalev/8169196/webrev.02/ Looks good - except for using a raw type at line 220: 220 Class ntlmProxyClass should be: Class ntlmP

RFR: 8169495: Add a method to set an Authenticator on a HttpURLConnection.

Hi, Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8169495 8169495: Add a method to set an Authenticator on a HttpURLConnection. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8169495/webrev.00 The public API changes are in java.net.HttpURLConnection and java.net.Au

Re: RFR 8162521, java/net/Authenticator/B4933582.sh fails intermittently with BindException

Hi Felix, Good to see one more script converted to java. I wonder if the fact that the test use to run two separate JVMs was significant. Hopefully it's not. The changes in TestHttpServer seem OK - this class is shared by many other tests - so any modifications here is to be taken with care. I

Re: RFR 8162521, java/net/Authenticator/B4933582.sh fails intermittently with BindException

On 01/12/16 14:40, Felix Yang wrote: Hi Daniel, please review the new webrev: http://cr.openjdk.java.net/~xiaofeya/8162521/webrev.01/ Looks good Felix! -- daniel Thanks, Felix On 2016/12/1 18:58, Daniel Fuchs wrote: Hi Felix, Good to see one more script converted to java. I wonder

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

Hi Felix, Looks good in general, but is 74 return; intended, or is that a test bug? best regards, -- daniel On 07/12/16 14:29, Felix Yang wrote: :-) -Felix On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: Add core-libs. Thanks, Felix On 2016/12/5 22:14, Felix Yang wrote

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

On 07/12/16 14:50, Chris Hegarty wrote: It is intended, as that is the code path that will be executed when the test invokes itself. Oh - right - I see it now. So looks good to me too :-) -- daniel -Chris. best regards, -- daniel On 07/12/16 14:29, Felix Yang wrote: :-) -Felix On 6

Re: RFR(s): 8170864: java/net/URLClassLoader/closetest/CloseTest.java has undeclared dependensies

Hi Sergei, On 07/12/16 15:01, Chris Hegarty wrote: On 7 Dec 2016, at 14:55, Sergei Kovalev wrote: Hi Team, Please review a simple fix for networking test. BugID: https://bugs.openjdk.java.net/browse/JDK-8170864 WebRev: http://cr.openjdk.java.net/~skovalev/8170864/webrev.00/ Issue: One of ne

RFR: 8171081: Put TimeoutOrderingTest in ProblemList for solaris-all

Hi, Please find below a trivial fix for: https://bugs.openjdk.java.net/browse/JDK-8171081 8171081: Put TimeoutOrderingTest in ProblemList for solaris-all The test is also marked intermittent. http://cr.openjdk.java.net/~dfuchs/webrev_8171081/webrev.00/ best regards, -- daniel

Re: RFR 8038079: Re-examine integration of SPNEGO authentication

Hi Pavel, This looks good to me. best regards, -- daniel On 13/12/16 12:28, Pavel Rappo wrote: Hello, Could you please review the following change for [1]? http://cr.openjdk.java.net/~prappo/8038079/webrev.00/ sun.net.www.protocol.http.HttpURLConnection defined in the java.base module

Re: RFR: 8172253 SetIfModifiedSince.java test fails with http return code 404

On 13/01/17 16:37, Michael McMahon wrote: Could I get the following test change reviewed please? Macos test failure almost certainly caused by the use of a system proxy. Fix is to explicitly specify that proxy must not be used. http://cr.openjdk.java.net/~michaelm/8172253/webrev.1/ Thanks, Mic

Re: RFR(S): 8173475 : java/net/HttpURLConnection/SetAuthenticator tests have undeclared dependency on java.logging module

+1 best regards, -- daniel On 27/01/17 12:43, Sergei Kovalev wrote: Hi All, Please review a small fix for tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8173475 WebRev: http://cr.openjdk.java.net/~skovalev/8173475/webrev.00/ Issue: Two tests fail in case of usage '--limit-module' co

RFR: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently

Hi, Please find below a fix for: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently https://bugs.openjdk.java.net/browse/JDK-8173315 After examining the logs it appears that the problem may be due to reusing a dynamically allocated local p

Re: RFR: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently

that effect in the change. Otherwise, the fix looks good. Thanks Michael! Here is the new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.00/ -- daniel Thanks, Michael On 02/02/2017, 16:11, Daniel Fuchs wrote: Hi, Please find below a fix for: 8173315: java/net

Re: RFR: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently

On 02/02/17 18:29, Daniel Fuchs wrote: Here is the new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.00/ I meant http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.01/ of course :-( -- daniel

Re: RFR: JDK-8174716,,java/net/httpclient/security/Driver.java failing in JDK 9

Looks good Michael. But I'm afraid the use of Utils.getFreePort() means we might continue to see this test failing intermittently now and then. best regards, -- daniel On 10/02/17 09:35, Michael McMahon wrote: This test has been failing since the introduction of the incubator mechanism but w

Re: RFR 8174745: Httpclient source update for JDK 8

Hi Michael, Looks good to me. best regards, -- daniel On 10/02/17 17:10, Michael McMahon wrote: Hi Could I get the following change reviewed please? It is an update to the httpclient code to make it easier to backport to JDK 8 for testing purposes. http://cr.openjdk.java.net/~michaelm/8174

RFR 8174833: java/net/httpclient/http2/BasicTest.java always fails but always report success

Hi, Please find below an almost trivial fix for an HTTP/2 test bug: 8174833: java/net/httpclient/http2/BasicTest.java always fails but always report success https://bugs.openjdk.java.net/browse/JDK-8174833 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8174833/webrev.00/ best regar

Re: RFR 8175274 Fix httpclient asynchronous usage

On 20/02/17 16:46, Michael McMahon wrote: Could I get the following httpclient change reviewed please? http://cr.openjdk.java.net/~michaelm/8175274/webrev.1/ Hi Michael, Looks good to me. Nice to see this patch getting in. best regards, -- daniel It fixes some issues with asynchronous re

Re: RFR [9] 8175261: Per-protocol setting for not working for JAR URLConnection defaultUseCaches

Hi Chris, Looks good to me as well. cheers, -- daniel On 20/02/17 16:14, Chris Hegarty wrote: The fix for 8163449 [1] "Allow per protocol setting for URLConnection defaultUseCaches", does not work for JAR URLs ( which embed URLs to the actual artifact ). The problem is that sun.net.www.proto

Re: RFR[9] 8164625: Pooled HttpConnection should be removed during close

On 23/02/17 17:31, Michael McMahon wrote: Hi Pavel The source change looks fine. I'm not sure how the test works though. How does it check that the connection is not retained? I agree with Michael. A small comment in the test main() to explain what's going on and what's being tested would be

Re: RFR[9] 8164625: Pooled HttpConnection should be removed during close

On 24/02/17 10:28, Pavel Rappo wrote: Michael, Daniel, updated in place. Looks good Pavel. cheers, -- daniel Thanks, -Pavel On 23 Feb 2017, at 17:31, Michael McMahon wrote: Hi Pavel The source change looks fine. I'm not sure how the test works though. How does it check that the conne

Re: RFR 8175814: HttpClient protocol version needs unspecified value

On 01/03/17 15:40, Michael McMahon wrote: Hi Could I get the following JDK 9 change reviewed, please? In addition to fixing the spec problem around HTTP version, it fixes an implementation issue with version also, where the per-request version (if set) was not being picked up. http://cr.openjdk

Re: RFR (xs) : 8177144 :sun/net/www/http/HttpClient/B8025710.java should run in ovm mode

Looks good to me Seán! best, -- daniel On 20/03/2017 16:11, Seán Coffey wrote: Looking for a simple review. Test should be run in ovm mode : https://bugs.openjdk.java.net/browse/JDK-8177144 diff --git a/test/sun/net/www/http/HttpClient/B8025710.java b/test/sun/net/www/http/HttpClient/B802571

9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

Hi, While analyzing some of the later failure traces reported for https://bugs.openjdk.java.net/browse/JDK-8170940 8170940: test/java/net/httpclient/TimeoutOrdering.java failing intermittently I began to suspect that this was not caused by a test bug. Looking at the timeout handling cod

Re: 9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

Hi Pavel, Thanks for taking a look! On 06/04/2017 13:28, Pavel Rappo wrote: Heya Daniel, 750 /** 751 * same as above but for errors 752 */ 753 void completeResponseExceptionally(Throwable t) { 754 synchronized (response_cfs) { 755 /

Re: 9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

On 06/04/2017 14:08, Daniel Fuchs wrote: The only reason I touched this method is because I noticed the possibility of ConcurrentModificationException if we reached there. Well - now that I think about it again CME would probably not have happened with the old code either since we broke out of

Re: 9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

On 06/04/2017 14:23, Pavel Rappo wrote: Though it indeed jumps out on you. Could we use an iterator here and rely on its remove implementation, since we know the implementation of the list? We could - there's another loop earlier in this file that uses an index (line 713) - so I just choose to

Re: 9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

On 07/04/2017 14:31, Chris Hegarty wrote: Daniel, On 06/04/17 11:32, Daniel Fuchs wrote: ... webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.00/ Looks good Daniel. Just a few comments. 1) Http1Exchange.java Can 'operations' now be made private,

Re: 9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

Hi Chris, Here is the new webrev - where I have incorporated your feedback. http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.01/ If I don't hear from you that's what I plan to push on Monday. best regards, -- daniel On 07/04/2017 15:12, Daniel Fuchs wrote: On 07/04/

Re: 9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

hat I no longer see failures on windows. best regards, -- daniel On 07/04/2017 18:07, Chris Hegarty wrote: On 7 Apr 2017, at 17:51, Daniel Fuchs wrote: Hi Chris, Here is the new webrev - where I have incorporated your feedback. http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.01/

[JDK 10] RFR: 8179273: sun.net.httpserver.LeftOverInputStream should stop attempting to drain the stream when the server is stopped

Hi, Please find below a fix for: 8179273: sun.net.httpserver.LeftOverInputStream should stop attempting to drain the stream when the server is stopped https://bugs.openjdk.java.net/browse/JDK-8179273 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8179273/webrev.00/ From the thread

Re: RFR 8175814: HttpClient protocol version needs unspecified value

another set of eyes looking at it though. best regards, -- daniel Thanks Michael On 06/03/2017, 11:29, Michael McMahon wrote: On 06/03/2017, 11:12, Chris Hegarty wrote: On 06/03/17 11:00, Daniel Fuchs wrote: On 01/03/17 15:40, Michael McMahon wrote: Hi Could I get the following JDK 9

Re: RFR [9] 8179392: Fix warnings in the httpclient javadoc

Looks good Chris! Maybe the copyright year should be updated as well? cheers, -- daniel On 27/04/2017 11:53, Chris Hegarty wrote: A few @param and @return tags have missing descriptions. The description wording, in a few cases, has just been taken from sibling method descriptions ( nothing ne

Re: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo

Hi Pavel, A few nits: jdk/incubator/http/WebSocket.java: line 501: should use {@linkplain Also (line 46 and 501) the link target #sendClose may cause trouble if sendClose is overloaded - so I wonder if it may be better to have the full prototype there: #sendClose(int, String) (though I gue

Re: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo

/rfc6455) best regards, -- daniel On 10/05/2017 12:03, Pavel Rappo wrote: Daniel, thanks a lot for looking into this! I've addressed most of your suggestions: http://cr.openjdk.java.net/~prappo/8179021/webrev.01/ On 9 May 2017, at 15:49, Daniel Fuchs wrote: Hi Pavel, A few nits:

Re: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, jdk.httpserver, jdk.net, jdk.sctp

Hi Kumar, Looks mostly good. I'm not too sure about the changes from to and to though. Now some of the package.html files in java.naming retain their Package Specification section, and others have it changed to Package Specification. best regards, -- daniel On 10/05/2017 19:57, Kumar Srin

Re: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, jdk.httpserver, jdk.net, jdk.sctp

Hi Kumar, On 12/05/2017 00:16, Kumar Srinivasan wrote: Hi Daniel, As Jon surmised, this is an ARIA/accessibility requirement, in that one can't have holes in the usage of h* tags, as javadoc tool itself uses h1 and h2, the API docs have to start with h3. With respect to your comment, the h2-

Re: RFR (9): 8180498 Remove httpclient internal APIs which supply ByteBuffers to read calls

Hi Michael, Looks good - but what purpose does the rxBuffer now serves in Exchange.java? If I'm not mistaken it's an empty 0 sized buffer that is never replaced... At the very least it should be final (and not volatile), but maybe getBuffer() could simply be removed here? best regards, -- dani

  1   2   3   4   5   6   7   8   9   10   >