gainst all the InetAddress objects returned
> by such an API?
> But this is a big task (mostly spec work I would guess) for the net-dev
> team.
>
> On Mon, Mar 11, 2019 at 9:55 AM Arthur Eubanks
> wrote:
>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8220083
>>
20083/webrev.02/
On Tue, Mar 12, 2019 at 5:00 AM Chris Hegarty
wrote:
> Hi Arthur,
>
>
> On 11 Mar 2019, at 18:14, Arthur Eubanks wrote:
>
> Updated copyright years (I asked around, it should be fine), updated
> commit message.
> http://cr.openjdk.java.net/~aeubanks/8220
Thanks!
Just curious, what tests did you run and under what environment?
On Tue, Mar 12, 2019 at 10:34 AM Chris Hegarty
wrote:
> Arthur,
>
> On 12 Mar 2019, at 16:59, Arthur Eubanks wrote:
>
> Thanks for creating the umbrella bug.
>
> Split long line.
> Added the
etAddress address) .
>
> Thanks,
> Vyom
>
> On Tue, Mar 12, 2019 at 10:30 PM Arthur Eubanks
> wrote:
>
>> Thanks for creating the umbrella bug.
>>
>> Split long line.
>> Added the HTTPTestServer.java and UrgentDataTest.java changes in Chris's
>>
Hi,
A fix for some sample code in MulticastSocket, which assumed that
String.length() == String.getBytes().length, which is not true for
non-ASCII Strings.
http://cr.openjdk.java.net/~aeubanks/8220585/webrev.00
Most of these eventually turn the String into a URL, so using a URL
directly should work?
jshell> URL u = new URL("http", "::1", 9002, "/")
u ==> http://[::1]:9002/
jshell> URL u = new URL("http",
InetAddress.getLoopbackAddress().getHostAddress(), 9002, "/")
u ==> http://127.0.0.1:9002/
jshell> UR
to add the
"[]". Unless we fix up all the existing tests and you'll be sure to catch
any future bad uses of the loopback address in URLs in tests :)
On Thu, Mar 14, 2019 at 12:19 PM Chris Hegarty
wrote:
> Arthur,
>
> On 14 Mar 2019, at 17:44, Arthur Eubanks wrote:
>
> Most of
Sounds good, I'll work on that.
On Fri, Mar 22, 2019 at 10:02 AM Chris Hegarty
wrote:
> Arthur,
>
> > On 19 Mar 2019, at 15:31, Arthur Eubanks wrote:
> >
> > (Sorry for the late response, I keep getting sidetracked by other stuff)
> >
> > Is there a
Hi,
This patch replaces hardcoded "http://127.0.0.1/"; in tests with a new
URIBuilder and InetAddress.getLoopbackAddress().getHostAddress(). Creating
a URIBuilder helper class was discussed in a previous thread on net-dev.
http://cr.openjdk.java.net/~aeubanks/8220575/webrev.00/index.html
One pro
Changed B6890349.java to use URL constructor.
Changed sequence of URIBuilder calls to `.host().port().path()`.
Added missing `.path("/")`.
Added logging for most of the constructed URLs.
PTAL:
http://cr.openjdk.java.net/~aeubanks/8220575/webrev.01/test/jdk/com/sun/net/httpserver/bugs/B6373555.java
> 1) test/jdk/java/net/ResponseCache/Test2.java
>
> 83 url = URIBuilder.newBuilder()
> 84 .scheme("http")
> 85 .loopback()
> 86 .port(port)
> 87 .path("/test/foo")
> 88 .toURLUnchecked();
> 89
>
> 1) The following test fails with this change, when run on an IPv6-only
> environment. The reason is that it contains a certificate that has
> the IPv4 loopback address, 127.0.0.1.
>
>
> sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
>
> Caused by: java.secu
Sounds good, thanks.
On Mon, Apr 1, 2019 at 6:11 AM Chris Hegarty
wrote:
> Arthur, others,
>
> In order to help track the all the IPv6 related work, we have the
> following issues:
>
> Improved IPv6 Support ( for implementation issues )
>https://bugs.openjdk.java.net/browse/JDK-8221681
>
> U
t of the test failed.
On Fri, Mar 29, 2019 at 12:59 PM Arthur Eubanks wrote:
> I had just started on this yesterday.
> I'll look at which of the tests we modified in our patches with ipv4/6
> detection. I'm worried that some of them may be disabling test coverage
> that shoul
o Daniel's suggestion of a ipv4_available()
utility.
On Wed, Apr 17, 2019 at 7:01 AM Chris Hegarty
wrote:
> Arthur,
>
> On 16/04/2019 22:34, Arthur Eubanks wrote:
> > Hi,
> >
> > Copied from the bug https://bugs.openjdk.java.net/browse/JDK-8222562:
> > S
On Wed, Apr 24, 2019 at 9:03 AM mark sheppard
wrote:
> an observation on IPv4_supported and IPV6_supported for your consideration
>
>
>
> both, IPv4_support and IPv6_support use socket creation in the
> appropriate AF domain as a
> a verification of support, but the v6 version also checks that
epts and rejects IPv4 calls to getifaddrs(), setsockopt(), and
socket(), but those will be fixed in the future, likely with changes to the
JDK itself.
On Tue, Apr 16, 2019 at 2:14 PM Arthur Eubanks wrote:
> > Regarding trusting the IPSupport, I have checked to make sure that it&#x
Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8223214
Bug description:
Currently, Inet6AddressImpl.loopbackAddress() will unconditionally choose
the IPv6 loopback address if java.net.preferIPv6Address is set to "system"
or "true", els
>
> Arthur,
>
> On 1 May 2019, at 23:53, Arthur Eubanks wrote:
>
> Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223214
>
>
> I think the changes are good.
>
> Minor comment: after this chang
*From: *Chris Hegarty
*Date: *Thu, May 16, 2019 at 3:52 AM
*To: *Arthur Eubanks
*Cc: *OpenJDK Network Dev list
Arthur,
>
> On 16 May 2019, at 00:24, Arthur Eubanks wrote:
>
> webrev: http://cr.openjdk.java.net/~aeubanks/8224014/webrev.00/
> bug: https://bugs.openjdk.java.net/bro
v6 instead?
>
> (Note: you can log a follow-up issue if you don't want to tackle
> that immediately)
>
> best regards,
>
> -- daniel
>
>
> On 16/05/2019 01:45, Arthur Eubanks wrote:
> > bug: https://bugs.openjdk.java.net/browse/JDK-8224019
> > webr
bug: https://bugs.openjdk.java.net/browse/JDK-8224635
webrev: http://cr.openjdk.java.net/~aeubanks/8224635/webrev.00/index.html
Test java/security/SecureClassLoader/DefineClass.java is failing after
JDK-8224256
This change reverts the changes in JDK-8224256 and adds back in the test.
bug: https://bugs.openjdk.java.net/browse/JDK-8224645
webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/
Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with
NoSuchElementException on Solaris.
java.util.NoSuchElementException
at java.base/java.util.Spliterators$
On Fri, May 24, 2019 at 1:56 PM Sean Mullan wrote:
> On 5/23/19 8:14 PM, Arthur Eubanks wrote:
> > Ping on a review from security-dev.
> >
> > On Fri, May 17, 2019 at 9:53 AM Chris Hegarty > <mailto:chris.hega...@oracle.com>> wrote:
> >
> >
>
> For the record I ran Arthur's webrev.01 through our test system and
> got no failures (just tested BasicMulticastTests.java).
>
> best regards,
>
> -- daniel
>
Thanks.
Moved NetworkConfiguration.printSystemConfiguration() to the beginning,
removed counting and printing the number of interfaces
>
> Moved NetworkConfiguration.printSystemConfiguration() to the beginning,
> removed counting and printing the number of interfaces/throwing
> SkippedException.
> new webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.02/
>
> This looks okay to me, the only thing is that the NetworkConfig
Ping on the updated webrev.
On Wed, May 29, 2019 at 1:08 PM Arthur Eubanks wrote:
> Moved NetworkConfiguration.printSystemConfiguration() to the beginning,
>> removed counting and printing the number of interfaces/throwing
>> SkippedException.
>> new webrev: http://cr.openj
t;
> > On 6 Jun 2019, at 12:13, Daniel Fuchs wrote:
> >
> > Hi Arthur,
> >
> > Looks good to me too.
> > I have run it through our test system and saw no issues.
> >
> > best regards,
> >
> > -- daniel
> >
> > On 04/06/2019 11:2
28 matches
Mail list logo
