Hello,
Please review this fix for 8u:
https://bugs.openjdk.java.net/browse/JDK-8047186
http://cr.openjdk.java.net/~asmotrak/so_flow_sla/sockets_exceptions/webrev.01/
getOption() and setOption() methods of jdk.net.Sockets class throw
InvocationTargetException instead of actual runtime exception
Hi Michael,
Yes, I think it is better to throw the original runtime exception.
Artem
On 06/18/2014 06:28 PM, Michael McMahon wrote:
On 18/06/14 13:53, Artem Smotrakov wrote:
Hello,
Please review this fix for 8u:
https://bugs.openjdk.java.net/browse/JDK-8047186
http://cr.openjdk.java.net
Hello,
Please review this fix for 9.
If a socket was created with Socket(Proxy) constructor [1], then it
doesn't take into account "socksProxyVersion" system property. As a
result, it is not possible to use SOCKS v4 (v5 is used by default [2]).
Currently the property is checked only in SocksS
Hello,
Please review this small fix which updates NTLM implementation to use
doPrivileged() methods when it reads system properties. Currently it
requires property permissions to read "ntlm.debug" and "ntlm.version"
system properties. Also added a test which runs NTLM auth if security
manager
Hello,
Please review this for 9.
According to [1], an HTTP client should try to use another HTTP
authentication scheme if negotiate process failed for some reason, and a
user didn't specify SPNEGO or Kerberos in "http.auth.preference" system
property. But no fallback happens if, for example:
t the AuthenticationHeader.authPref string out with the
"Negotiate process failed, fallback" logger message. It's a useful
variable to capture.
Regards,
Sean.
On 07/10/2015 12:19, Artem Smotrakov wrote:
Hello,
Please review this for 9.
According to [1], an HTTP client should try
ss for a long time and I could be wrong.
Thanks
Max
On Oct 7, 2015, at 7:19 PM, Artem Smotrakov wrote:
Hello,
Please review this for 9.
According to [1], an HTTP client should try to use another HTTP authentication scheme if
negotiate process failed for some reason, and a user didn't specif
Please see updated webrev
http://cr.openjdk.java.net/~asmotrak/8138953/webrev.01/
Artem
On 10/07/2015 06:51 PM, Artem Smotrakov wrote:
Hi Max,
HttpURLConnection obtains credentials for HTTP authentication from
Authenticator [1] implementation. Only one authenticator can be set in
JVM
On 10/08/2015 11:41 AM, Wang Weijun wrote:
On Oct 7, 2015, at 11:51 PM, Artem Smotrakov wrote:
Hi Max,
HttpURLConnection obtains credentials for HTTP authentication from
Authenticator [1] implementation. Only one authenticator can be set in JVM
instance. It can have built-in crede
Hi Max,
Please see inline.
On 10/16/2015 05:18 AM, Wang Weijun wrote:
Let's go back to the bug description:
But no fallback happens if:
1. an HTTP server supports both Negotiate (via Kerberos) and Basic
authentication schemes
2. first, a user provides correct Kerberos credentials, and a conn
Hi Mark,
I am not a reviewer, just have a couple of comments about InetAddress.java
1. It may be better to create an instance of Scanner in
try-with-resource block to be sure that Scanner.close() method is called.
2. Lines 909-923:
There are two similar "if" blocks in the loop. Looks like th
Hi Svetlana,
I'll leave the mail review to official reviewers, a couple of minor
comments about your test.
It seems to work fine, but you may want to use "else if" in
UnsupportedOptionsTest.getOption() method because "Unsupported socket
type" error can occure in case of supported socket type
Hello,
Please review this small fix for DigestAuthentication class.
1. Added a check in DigestAuthentication.setNonce(String) that nonce is
not null. NPE may happen if a buggy HTTP server returns
"WWW-Authenticate" header which doesn't contain a "nonce" field.
According to RFCs 2069 [1] and 2
digest/webrev.01/
Artem
On 12/22/2015 05:59 AM, Michael McMahon wrote:
Hi Artem,
On 04/12/15 11:41, Artem Smotrakov wrote:
Hello,
Please review this small fix for DigestAuthentication class.
1. Added a check in DigestAuthentication.setNonce(String) that nonce
is not null. NPE may happen
Hi Michael,
On 01/04/2016 02:28 AM, Michael McMahon wrote:
On 30/12/15 03:22, Artem Smotrakov wrote:
Hi Michael,
Thanks for review, it looks like BNF notation uses only a comma as a
separator
http://www.w3.org/Notation.html
...
#element
indicating at least l and at most m elements, each
Hello,
Please review this for 9.
Stream.getResponse() method can hang because it calls join() method
without any timeout. It would be better if it took into account a
timeout value specified for a connection, and threw HttpTimeoutException
if timeout was reached.
The patch updates Stream.ge
Hello,
Please review this patch for 9.
NPE may occur if additional logging is enabled with
"java.net.http.HttpClient.log" system property because
AsyncSSLDelegate.logParams(SSLParameters) doesn't check for null values
which were returned by SSLParameters instance.
I also noticed that settin
Hi Svetlana,
Please see a couple of comments below. I'll leave the final review to
official reviewers.
1. You may use test/lib/testlibrary/jdk/testlibrary/OSInfo.java to check
OS type. I think it also may be good to add getSolarisVersion() to
OSInfo.java (see getWindowsVersion() method)
Yo
Hi Svetlana,
I am not an official reviewer, but I have a couple comments below.
TestFtpClientNameListWithNull.java:
1. Shouldn't "commandHasArgs" be volatile? Looks like it may cause
intermittent failures. As a sanity check, you may want to run the test
in a loop to make sure it is stable.
our replay. I believe I addressed all your comments.
Please see updated diff:
http://cr.openjdk.java.net/~snikandrova/8022580/webrev.01/
<http://cr.openjdk.java.net/%7Esnikandrova/8022580/webrev.01/>
Thank you,
Svetlana
On 05.07.2016 20:54, Artem Smotrakov wrote:
Hi Svetlana,
I am not an official reviewe
ke you have already looked into that issue before. May be you
can find some time to review this fix?
Thank you,
Svetlana
On 06.07.2016 20:35, Artem Smotrakov wrote:
Hi Svetlana,
Thanks for addressing my comments. Could you please take a look at a
couple of comments about TestFtpClientNameListWi
Hello,
Please review the following patch for NoLoopbackPackets.java test.
The test starts a daemon thread which has an infinite loop. If jtreg
uses the same JVM to run multiple tests (agent VM), then this thread
will be keep running until the agent VM stops. This is not good, it
would be bett
Sending to net-dev@openjdk.java.net as well.
Artem
On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
Hello,
Please review the following patch for
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
The test has been observed to fail a couple of times, but it's still
not clea
Not urgent, but I would appreciate if someone can get a chance to look
at this.
Artem
On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
Sending to net-dev@openjdk.java.net as well.
Artem
On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
Hello,
Please review the following patch for
sun/net
SSLSocketSample.java template as the comment in JDK-8163924 review
thread.
Thanks,
Xuelei
On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
Not urgent, but I would appreciate if someone can get a chance to look
at this.
Artem
On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
Sending to net-dev
it's going to
help, so I would like to keep debug output on.
Artem
On 09/14/2016 06:39 PM, Xuelei Fan wrote:
On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
Hi Xuelei,
For this one, I am not sure that it would help here since the test
failed after it already had started handshaking.
I
Hi Xuelei, Chris,
Thank you for looking into it. Please see inline.
On 09/15/2016 12:53 AM, Chris Hegarty wrote:
On 15 Sep 2016, at 02:55, Xuelei Fan wrote:
On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
Well, in this particular case it's not clear that it has the same issue
with free
Artem Smotrakov wrote:
Hi Xuelei, Chris,
Thank you for looking into it. Please see inline.
On 09/15/2016 12:53 AM, Chris Hegarty wrote:
On 15 Sep 2016, at 02:55, Xuelei Fan wrote:
On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
Well, in this particular case it's not clear that it has the s
Hello,
Please review the patch below for
sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test.
The test has been observed to fail intermittently, but the failure is
not reproducible standalone. The patch updates the test to follow the
approach from SSLSocketSample.java
http://hg.
Hello,
Please take a look.
Artem
On 10/07/2016 01:33 PM, Artem Smotrakov wrote:
Hello,
Please review the patch below for
sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test.
The test has been observed to fail intermittently, but the failure is
not reproducible standalone. The
30 matches
Mail list logo
