From chris.hegarty at oracle.com  Tue Apr 14 16:24:16 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 14 Apr 2015 17:24:16 +0100
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a
	fallback for migration
Message-ID: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>

The work done as part of JDK-8064924 [1] to introduce a new service type, java.net.spi.URLStreamHandlerProvider, provides a clean provider mechanism that will work well with modules. That part of the change should remain, but the removal of support to find handlers through the java.protocol.handler.pkgs system property is problematic, and could be an impediment to moving to JDK 9. Applications making use of custom protocol handlers and not packaged as modules should continue to be able to use this property.

The proposal is to reinstate the JDK 8 specification about java.protocol.handler.pkgs in java.net.URL.<init>, that documents the search order for handlers. Additionally reinstate the JDK 8 implementation code to search the system property after the service loader lookup.

http://cr.openjdk.java.net/~chegar/8075139/webrev.00/

The spec and code changes in the above webrev are almost identical to the original code pre 8064924.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8064924

From Alan.Bateman at oracle.com  Tue Apr 14 19:33:17 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 14 Apr 2015 20:33:17 +0100
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as
	a fallback for migration
In-Reply-To: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>
Message-ID: <552D6B7D.8010107@oracle.com>

On 14/04/2015 17:24, Chris Hegarty wrote:
> The work done as part of JDK-8064924 [1] to introduce a new service type, java.net.spi.URLStreamHandlerProvider, provides a clean provider mechanism that will work well with modules. That part of the change should remain, but the removal of support to find handlers through the java.protocol.handler.pkgs system property is problematic, and could be an impediment to moving to JDK 9. Applications making use of custom protocol handlers and not packaged as modules should continue to be able to use this property.
>
> The proposal is to reinstate the JDK 8 specification about java.protocol.handler.pkgs in java.net.URL.<init>, that documents the search order for handlers. Additionally reinstate the JDK 8 implementation code to search the system property after the service loader lookup.
>
> http://cr.openjdk.java.net/~chegar/8075139/webrev.00/
>
> The spec and code changes in the above webrev are almost identical to the original code pre 8064924.
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8064924
This looks okay to me although maybe we can use the opportunity to 
replace the use of StringTokenizer with a regex.

One comment on the javadoc is that it says "the constructors finds the 
value of the system property", I assume this should be "reads" rather 
than "finds". Also you can use {@code ...} in the blockquote to avoid 
the escaping.

-Alan

From paul.sandoz at oracle.com  Wed Apr 15 09:36:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 15 Apr 2015 11:36:20 +0200
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a
	fallback for migration
In-Reply-To: <552D6B7D.8010107@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>
	<552D6B7D.8010107@oracle.com>
Message-ID: <A1B85D49-9691-4E57-9D72-173100D41610@oracle.com>


On Apr 14, 2015, at 9:33 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 14/04/2015 17:24, Chris Hegarty wrote:
>> The work done as part of JDK-8064924 [1] to introduce a new service type, java.net.spi.URLStreamHandlerProvider, provides a clean provider mechanism that will work well with modules. That part of the change should remain, but the removal of support to find handlers through the java.protocol.handler.pkgs system property is problematic, and could be an impediment to moving to JDK 9. Applications making use of custom protocol handlers and not packaged as modules should continue to be able to use this property.
>> 
>> The proposal is to reinstate the JDK 8 specification about java.protocol.handler.pkgs in java.net.URL.<init>, that documents the search order for handlers. Additionally reinstate the JDK 8 implementation code to search the system property after the service loader lookup.
>> 
>> http://cr.openjdk.java.net/~chegar/8075139/webrev.00/
>> 
>> The spec and code changes in the above webrev are almost identical to the original code pre 8064924.
>> 
>> -Chris.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8064924
> This looks okay to me although maybe we can use the opportunity to replace the use of StringTokenizer with a regex.
> 

Yes, one could use a Pattern.splitAsStream, sorry could not resist :-) assuming this area is not sensitive to bootstrap issues e.g.

  hander = p.splitAsStream().map(String::trim).flatMap(this::getHandler).findFirst().orElse(null);

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20150415/fab87f18/signature.asc>

From Alan.Bateman at oracle.com  Wed Apr 15 11:35:48 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Apr 2015 12:35:48 +0100
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as
	a fallback for migration
In-Reply-To: <A1B85D49-9691-4E57-9D72-173100D41610@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>	<552D6B7D.8010107@oracle.com>
	<A1B85D49-9691-4E57-9D72-173100D41610@oracle.com>
Message-ID: <552E4D14.4050102@oracle.com>

On 15/04/2015 10:36, Paul Sandoz wrote:
> :
>
> Yes, one could use a Pattern.splitAsStream, sorry could not resist :-) assuming this area is not sensitive to bootstrap issues e.g.
>
>    hander = p.splitAsStream().map(String::trim).flatMap(this::getHandler).findFirst().orElse(null);
>
This is a fallback for custom protocol handlers so there shouldn't be 
any bootstrapping or performance issues here. If this were for the core 
protocol handlers loaded early in startup then it might need a closer 
look (and performance/startup measurements).

-Alan

From chris.hegarty at oracle.com  Wed Apr 15 11:36:01 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 Apr 2015 12:36:01 +0100
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as
	a fallback for migration
In-Reply-To: <552D6B7D.8010107@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>
	<552D6B7D.8010107@oracle.com>
Message-ID: <552E4D21.1070507@oracle.com>

On 14/04/15 20:33, Alan Bateman wrote:
> ....
> This looks okay to me although maybe we can use the opportunity to
> replace the use of StringTokenizer with a regex.

Right. I used String.split("\\|"), but reverted to the original code as 
the regex doesn't use the fast-path. But you are right split is probably 
better.

> One comment on the javadoc is that it says "the constructors finds the
> value of the system property", I assume this should be "reads" rather
> than "finds".

Thanks. This was a typo in the original spec. Fixed.

 >  Also you can use {@code ...} in the blockquote to avoid
> the escaping.

Done. We have lost the italic font, but that should be fine.

The above changes are capture here
   http://cr.openjdk.java.net/~chegar/8075139/webrev.01/


Paul,

 >
 > Yes, one could use a Pattern.splitAsStream, sorry could not resist 
:-) assuming this area is not sensitive to bootstrap issues e.g.
 >
 >    hander = 
p.splitAsStream().map(String::trim).flatMap(this::getHandler).findFirst().orElse(null);

With the restriction we now have on overriding "core" protocol handlers 
we can actually use lambda's in this specific code path. I built a 
webrev based on your suggestion. Not too bad. I marginally favor this 
over webrev.01 above.

http://cr.openjdk.java.net/~chegar/8075139/webrev.02/src/java.base/share/classes/java/net/URL.java.sdiff.html

-Chris.

From paul.sandoz at oracle.com  Wed Apr 15 14:16:34 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 15 Apr 2015 16:16:34 +0200
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a
	fallback for migration
In-Reply-To: <552E4D21.1070507@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>
	<552D6B7D.8010107@oracle.com> <552E4D21.1070507@oracle.com>
Message-ID: <84C8D355-FEA0-4C62-83AD-4F2C008A2500@oracle.com>

On Apr 15, 2015, at 1:36 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Paul,
> 
> >
> > Yes, one could use a Pattern.splitAsStream, sorry could not resist :-) assuming this area is not sensitive to bootstrap issues e.g.
> >
> >    hander = p.splitAsStream().map(String::trim).flatMap(this::getHandler).findFirst().orElse(null);
> 
> With the restriction we now have on overriding "core" protocol handlers we can actually use lambda's in this specific code path. I built a webrev based on your suggestion. Not too bad. I marginally favor this over webrev.01 above.
> 
> http://cr.openjdk.java.net/~chegar/8075139/webrev.02/src/java.base/share/classes/java/net/URL.java.sdiff.html
> 

Looks ok. 

I marginally prefer using flatMap rather than map/filter e.g. change getHandler to return Stream< URLStreamHandler> and change the last line to be "return Stream.ofNullable(handle). Up to you. 

If you stick with what you have perhaps consider changing "h -> h != null" to "Objects::nonNull".

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20150415/37c19499/signature.asc>

From chris.hegarty at oracle.com  Wed Apr 15 14:35:49 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 15 Apr 2015 15:35:49 +0100
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as
	a fallback for migration
In-Reply-To: <84C8D355-FEA0-4C62-83AD-4F2C008A2500@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>	<552D6B7D.8010107@oracle.com>
	<552E4D21.1070507@oracle.com>
	<84C8D355-FEA0-4C62-83AD-4F2C008A2500@oracle.com>
Message-ID: <552E7745.40105@oracle.com>

On 15/04/15 15:16, Paul Sandoz wrote:
> On Apr 15, 2015, at 1:36 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>
>> Paul,
>>
>>>
>>> Yes, one could use a Pattern.splitAsStream, sorry could not resist :-) assuming this area is not sensitive to bootstrap issues e.g.
>>>
>>>     hander = p.splitAsStream().map(String::trim).flatMap(this::getHandler).findFirst().orElse(null);
>>
>> With the restriction we now have on overriding "core" protocol handlers we can actually use lambda's in this specific code path. I built a webrev based on your suggestion. Not too bad. I marginally favor this over webrev.01 above.
>>
>> http://cr.openjdk.java.net/~chegar/8075139/webrev.02/src/java.base/share/classes/java/net/URL.java.sdiff.html
>>
>
> Looks ok.
>
> I marginally prefer using flatMap rather than map/filter e.g. change getHandler to return Stream< URLStreamHandler> and change the last line to be "return Stream.ofNullable(handle). Up to you.

That's better. For completeness, the updated webrev:
   http://cr.openjdk.java.net/~chegar/8075139/webrev.03/

-Chris.

> If you stick with what you have perhaps consider changing "h -> h != null" to "Objects::nonNull".
>
> Paul.
>

From Alan.Bateman at oracle.com  Wed Apr 15 14:41:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 15 Apr 2015 15:41:23 +0100
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as
	a fallback for migration
In-Reply-To: <552E7745.40105@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>	<552D6B7D.8010107@oracle.com>	<552E4D21.1070507@oracle.com>	<84C8D355-FEA0-4C62-83AD-4F2C008A2500@oracle.com>
	<552E7745.40105@oracle.com>
Message-ID: <552E7893.6000909@oracle.com>

On 15/04/2015 15:35, Chris Hegarty wrote:
>
> That's better. For completeness, the updated webrev:
>   http://cr.openjdk.java.net/~chegar/8075139/webrev.03/
Either is okay with me, the main thing is that the legacy tokenizer is gone.

-Alan.

From paul.sandoz at oracle.com  Wed Apr 15 15:43:38 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 15 Apr 2015 17:43:38 +0200
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a
	fallback for migration
In-Reply-To: <552E7745.40105@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>	<552D6B7D.8010107@oracle.com>
	<552E4D21.1070507@oracle.com>
	<84C8D355-FEA0-4C62-83AD-4F2C008A2500@oracle.com>
	<552E7745.40105@oracle.com>
Message-ID: <0C0943A8-96B3-40A7-AD00-2C8D3284EFCA@oracle.com>

On Apr 15, 2015, at 4:35 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> I marginally prefer using flatMap rather than map/filter e.g. change getHandler to return Stream< URLStreamHandler> and change the last line to be "return Stream.ofNullable(handle). Up to you.
> 
> That's better. For completeness, the updated webrev:
>  http://cr.openjdk.java.net/~chegar/8075139/webrev.03/

Looks good,
Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20150415/e7f0a7e7/signature.asc>

From sgehwolf at redhat.com  Mon Apr 20 12:14:46 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 20 Apr 2015 14:14:46 +0200
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <1429531333.3444.14.camel@redhat.com>
References: <1429531333.3444.14.camel@redhat.com>
Message-ID: <1429532086.3444.15.camel@redhat.com>

Adding in net-dev.

On Mon, 2015-04-20 at 14:02 +0200, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review and a sponsor for the following patch?
> 
> The issue is that JDK's internal /etc/resolv.conf nameserver parsing
> does not properly account for IPv6 addresses on Linux/Unix. While the
> code in com.sun.jndi.dns.DnsClient seems to support IPv6 addresses
> passed in via the servers list in the constructor it expects IPv6
> addresses to be wrapped in '[' and ']' respectively. However,
> sun.net.dns.ResolverConfigurationImpl does no wrapping of IPv6 addresses
> when parsing "nameserver" keywords from /etc/resolv.conf, thus breaking
> DnsClient's contract.
> 
> The fix is to properly wrap IPv6 literal addresses in '[' and ']' if not
> already wrapped.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-6991580
> Webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.01/
> 
> Testing done: Added regression test fails for unpatched 9 and passes for
> patched 9.
> 
> Thanks,
> Severin
> 




From gnu.andrew at redhat.com  Mon Apr 20 16:24:24 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 20 Apr 2015 12:24:24 -0400 (EDT)
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <1429532086.3444.15.camel@redhat.com>
References: <1429531333.3444.14.camel@redhat.com>
	<1429532086.3444.15.camel@redhat.com>
Message-ID: <692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>

----- Original Message -----
> Adding in net-dev.
> 
> On Mon, 2015-04-20 at 14:02 +0200, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get a review and a sponsor for the following patch?
> > 
> > The issue is that JDK's internal /etc/resolv.conf nameserver parsing
> > does not properly account for IPv6 addresses on Linux/Unix. While the
> > code in com.sun.jndi.dns.DnsClient seems to support IPv6 addresses
> > passed in via the servers list in the constructor it expects IPv6
> > addresses to be wrapped in '[' and ']' respectively. However,
> > sun.net.dns.ResolverConfigurationImpl does no wrapping of IPv6 addresses
> > when parsing "nameserver" keywords from /etc/resolv.conf, thus breaking
> > DnsClient's contract.
> > 
> > The fix is to properly wrap IPv6 literal addresses in '[' and ']' if not
> > already wrapped.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-6991580
> > Webrev:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.01/
> > 
> > Testing done: Added regression test fails for unpatched 9 and passes for
> > patched 9.
> > 
> > Thanks,
> > Severin
> > 
> 
> 
> 
> 

It'd be better to provide public nameservers in the test comment so everyone
is able to run this test if they update /etc/resolv.conf appropriately.

Google provides some: https://developers.google.com/speed/public-dns/docs/using

$ host redhat.com 2001:4860:4860::8888
Using domain server:
Name: 2001:4860:4860::8888
Address: 2001:4860:4860::8888#53
Aliases: 

redhat.com has address 209.132.183.105
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From sgehwolf at redhat.com  Mon Apr 20 17:32:20 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 20 Apr 2015 19:32:20 +0200
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>
References: <1429531333.3444.14.camel@redhat.com>
	<1429532086.3444.15.camel@redhat.com>
	<692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>
Message-ID: <1429551140.3444.39.camel@redhat.com>

On Mon, 2015-04-20 at 12:24 -0400, Andrew Hughes wrote:
> ----- Original Message -----
> > Adding in net-dev.
> > 
> > On Mon, 2015-04-20 at 14:02 +0200, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > Could I please get a review and a sponsor for the following patch?
> > > 
> > > The issue is that JDK's internal /etc/resolv.conf nameserver parsing
> > > does not properly account for IPv6 addresses on Linux/Unix. While the
> > > code in com.sun.jndi.dns.DnsClient seems to support IPv6 addresses
> > > passed in via the servers list in the constructor it expects IPv6
> > > addresses to be wrapped in '[' and ']' respectively. However,
> > > sun.net.dns.ResolverConfigurationImpl does no wrapping of IPv6 addresses
> > > when parsing "nameserver" keywords from /etc/resolv.conf, thus breaking
> > > DnsClient's contract.
> > > 
> > > The fix is to properly wrap IPv6 literal addresses in '[' and ']' if not
> > > already wrapped.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-6991580
> > > Webrev:
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.01/
> > > 
> > > Testing done: Added regression test fails for unpatched 9 and passes for
> > > patched 9.
> > > 
> > > Thanks,
> > > Severin
> > > 
> > 
> > 
> > 
> > 
> 
> It'd be better to provide public nameservers in the test comment so everyone
> is able to run this test if they update /etc/resolv.conf appropriately.

OK fixed:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.02/

FWIW, I don't think the test needs IP addresses of DNS servers to be
functional, though. All it really does is passing it to
InetAddress.getByName(). Prior this patch DnsClient fails to parse the
IP literals.

> Google provides some: https://developers.google.com/speed/public-dns/docs/using
> 
> $ host redhat.com 2001:4860:4860::8888
> Using domain server:
> Name: 2001:4860:4860::8888
> Address: 2001:4860:4860::8888#53
> Aliases: 
> 
> redhat.com has address 209.132.183.105

On my F21 machine:
$ host redhat.com 2001:4860:4860::8888
;; connection timed out; no servers could be reached

But the test still works with a patched JDK:
[...]
DEBUG: 'nameserver = 127.0.0.1'
DEBUG: 'nameserver = [2001:4860:4860::8888]'
DEBUG: ==> Found IPv6 address in servers list: [2001:4860:4860::8888]
DEBUG: 'nameserver = [::1]:5353'
DEBUG: ==> Found IPv6 address in servers list: [::1]:5353
DEBUG: 'nameserver = 127.0.0.1:5353'
PASS: Found IPv6 address and DnsClient parsed it correctly.

Contrast this to unpatched:
[...]
DEBUG: 'nameserver = 127.0.0.1'
DEBUG: 'nameserver = 2001:4860:4860::8888'
DEBUG: ==> Found IPv6 address in servers list: 2001:4860:4860::8888
DEBUG: 'nameserver = [::1]:5353'
DEBUG: ==> Found IPv6 address in servers list: [::1]:5353
DEBUG: 'nameserver = 127.0.0.1:5353'
Exception in thread "main" java.lang.RuntimeException: FAIL: Tried to parse non-[]-encapsulated IPv6 address.
	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:59)
Caused by: java.lang.NumberFormatException: For input string: "4860:4860::8888"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:580)
	at java.lang.Integer.parseInt(Integer.java:615)
	at com.sun.jndi.dns.DnsClient.<init>(DnsClient.java:127)
	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:57)

Cheers,
Severin


From michael.x.mcmahon at oracle.com  Tue Apr 21 09:58:33 2015
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 21 Apr 2015 10:58:33 +0100
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <1429551140.3444.39.camel@redhat.com>
References: <1429531333.3444.14.camel@redhat.com>	<1429532086.3444.15.camel@redhat.com>	<692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>
	<1429551140.3444.39.camel@redhat.com>
Message-ID: <55361F49.4050700@oracle.com>

On 20/04/15 18:32, Severin Gehwolf wrote:
> On Mon, 2015-04-20 at 12:24 -0400, Andrew Hughes wrote:
>> ----- Original Message -----
>>> Adding in net-dev.
>>>
>>> On Mon, 2015-04-20 at 14:02 +0200, Severin Gehwolf wrote:
>>>> Hi,
>>>>
>>>> Could I please get a review and a sponsor for the following patch?
>>>>
>>>> The issue is that JDK's internal /etc/resolv.conf nameserver parsing
>>>> does not properly account for IPv6 addresses on Linux/Unix. While the
>>>> code in com.sun.jndi.dns.DnsClient seems to support IPv6 addresses
>>>> passed in via the servers list in the constructor it expects IPv6
>>>> addresses to be wrapped in '[' and ']' respectively. However,
>>>> sun.net.dns.ResolverConfigurationImpl does no wrapping of IPv6 addresses
>>>> when parsing "nameserver" keywords from /etc/resolv.conf, thus breaking
>>>> DnsClient's contract.
>>>>
>>>> The fix is to properly wrap IPv6 literal addresses in '[' and ']' if not
>>>> already wrapped.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6991580
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.01/
>>>>
>>>> Testing done: Added regression test fails for unpatched 9 and passes for
>>>> patched 9.
>>>>
>>>> Thanks,
>>>> Severin
>>>>
>>>
>>>
>>>
>> It'd be better to provide public nameservers in the test comment so everyone
>> is able to run this test if they update /etc/resolv.conf appropriately.
> OK fixed:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.02/
>
> FWIW, I don't think the test needs IP addresses of DNS servers to be
> functional, though. All it really does is passing it to
> InetAddress.getByName(). Prior this patch DnsClient fails to parse the
> IP literals.

That's true, but no harm having a public IP address there anyway.
I can sponsor this change for you.

- Michael


>> Google provides some: https://developers.google.com/speed/public-dns/docs/using
>>
>> $ host redhat.com 2001:4860:4860::8888
>> Using domain server:
>> Name: 2001:4860:4860::8888
>> Address: 2001:4860:4860::8888#53
>> Aliases:
>>
>> redhat.com has address 209.132.183.105
> On my F21 machine:
> $ host redhat.com 2001:4860:4860::8888
> ;; connection timed out; no servers could be reached
>
> But the test still works with a patched JDK:
> [...]
> DEBUG: 'nameserver = 127.0.0.1'
> DEBUG: 'nameserver = [2001:4860:4860::8888]'
> DEBUG: ==> Found IPv6 address in servers list: [2001:4860:4860::8888]
> DEBUG: 'nameserver = [::1]:5353'
> DEBUG: ==> Found IPv6 address in servers list: [::1]:5353
> DEBUG: 'nameserver = 127.0.0.1:5353'
> PASS: Found IPv6 address and DnsClient parsed it correctly.
>
> Contrast this to unpatched:
> [...]
> DEBUG: 'nameserver = 127.0.0.1'
> DEBUG: 'nameserver = 2001:4860:4860::8888'
> DEBUG: ==> Found IPv6 address in servers list: 2001:4860:4860::8888
> DEBUG: 'nameserver = [::1]:5353'
> DEBUG: ==> Found IPv6 address in servers list: [::1]:5353
> DEBUG: 'nameserver = 127.0.0.1:5353'
> Exception in thread "main" java.lang.RuntimeException: FAIL: Tried to parse non-[]-encapsulated IPv6 address.
> 	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:59)
> Caused by: java.lang.NumberFormatException: For input string: "4860:4860::8888"
> 	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> 	at java.lang.Integer.parseInt(Integer.java:580)
> 	at java.lang.Integer.parseInt(Integer.java:615)
> 	at com.sun.jndi.dns.DnsClient.<init>(DnsClient.java:127)
> 	at IPv6NameserverPlatformParsingTest.main(IPv6NameserverPlatformParsingTest.java:57)
>
> Cheers,
> Severin
>


From chris.hegarty at oracle.com  Tue Apr 21 10:20:05 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 21 Apr 2015 11:20:05 +0100
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a
	fallback for migration
In-Reply-To: <0C0943A8-96B3-40A7-AD00-2C8D3284EFCA@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>	<552D6B7D.8010107@oracle.com>
	<552E4D21.1070507@oracle.com>
	<84C8D355-FEA0-4C62-83AD-4F2C008A2500@oracle.com>
	<552E7745.40105@oracle.com>
	<0C0943A8-96B3-40A7-AD00-2C8D3284EFCA@oracle.com>
Message-ID: <04397A3E-6940-47F5-A43A-16D07BC8FCFB@oracle.com>

On 15 Apr 2015, at 16:43, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On Apr 15, 2015, at 4:35 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>> 
>>> I marginally prefer using flatMap rather than map/filter e.g. change getHandler to return Stream< URLStreamHandler> and change the last line to be "return Stream.ofNullable(handle). Up to you.
>> 
>> That's better. For completeness, the updated webrev:
>> http://cr.openjdk.java.net/~chegar/8075139/webrev.03/

Argh! The launcher is now falling over with "Error occurred during initialization of VM?, in cases where a custom policy file contains a URL [*].

I?ll revert back to the version pre streams and lambda.

http://cr.openjdk.java.net/~chegar/8075139/webrev.01/

-Chris.

[*] Error occurred during initialization of VM
java.lang.NoClassDefFoundError: Could not initialize class java.lang.invoke.LambdaForm
	at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223)
	at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188)
	at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177)
	at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84)
	at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1656)
	at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1613)
	at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1798)
	at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1747)
	at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477)
	at java.net.URL.lookupViaProperty(URL.java:1185)
	at java.net.URL.getURLStreamHandler(URL.java:1309)
	at java.net.URL.<init>(URL.java:615)
	at java.net.URL.<init>(URL.java:506)
	at java.net.URL.<init>(URL.java:455)
	at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:210)
	at javax.crypto.SecretKeyFactory.nextSpi(SecretKeyFactory.java:295)
	at javax.crypto.SecretKeyFactory.<init>(SecretKeyFactory.java:121)
	at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:160)
	at sun.security.pkcs12.PKCS12KeyStore.getPBEKey(PKCS12KeyStore.java:815)
	at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2013)
	at java.security.KeyStore.load(KeyStore.java:1459)
	at sun.security.util.PolicyUtil.getKeyStore(PolicyUtil.java:166)
	at sun.security.provider.PolicyFile.init(PolicyFile.java:610)
	at sun.security.provider.PolicyFile.access$400(PolicyFile.java:258)
	at sun.security.provider.PolicyFile$3.run(PolicyFile.java:521)
	at sun.security.provider.PolicyFile$3.run(PolicyFile.java:495)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:495)
	at sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:480)
	at sun.security.provider.PolicyFile.init(PolicyFile.java:439)
	at sun.security.provider.PolicyFile.<init>(PolicyFile.java:297)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:425)
	at java.lang.Class.newInstance(Class.java:464)
	at java.security.Policy.getPolicyNoCheck(Policy.java:184)
	at java.security.ProtectionDomain.implies(ProtectionDomain.java:278)
	at java.lang.System$1.run(System.java:315)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.lang.System.setSecurityManager0(System.java:312)
	at java.lang.System.setSecurityManager(System.java:290)
	at sun.misc.Launcher.<init>(Launcher.java:109)
	at sun.misc.Launcher.<clinit>(Launcher.java:64)
	at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1443)
	at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1428)

From Alan.Bateman at oracle.com  Tue Apr 21 10:32:49 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Apr 2015 11:32:49 +0100
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as
	a fallback for migration
In-Reply-To: <04397A3E-6940-47F5-A43A-16D07BC8FCFB@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>	<552D6B7D.8010107@oracle.com>
	<552E4D21.1070507@oracle.com>
	<84C8D355-FEA0-4C62-83AD-4F2C008A2500@oracle.com>
	<552E7745.40105@oracle.com>
	<0C0943A8-96B3-40A7-AD00-2C8D3284EFCA@oracle.com>
	<04397A3E-6940-47F5-A43A-16D07BC8FCFB@oracle.com>
Message-ID: <55362751.3030609@oracle.com>



On 21/04/2015 11:20, Chris Hegarty wrote:
> On 15 Apr 2015, at 16:43, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> On Apr 15, 2015, at 4:35 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>> I marginally prefer using flatMap rather than map/filter e.g. change getHandler to return Stream< URLStreamHandler> and change the last line to be "return Stream.ofNullable(handle). Up to you.
>>> That's better. For completeness, the updated webrev:
>>> http://cr.openjdk.java.net/~chegar/8075139/webrev.03/
> Argh! The launcher is now falling over with "Error occurred during initialization of VM?, in cases where a custom policy file contains a URL [*].
>
> I?ll revert back to the version pre streams and lambda.
>
> http://cr.openjdk.java.net/~chegar/8075139/webrev.01/
>
This seems fine for now.

Peter Levart was looking into some of these initialization issues 
recently on mlvm-dev [1]. Issues can show up in many ways and would be 
good to solve some of these in JDK 9 if we can.

-Alan

[1] http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-March/006386.html

From paul.sandoz at oracle.com  Tue Apr 21 12:08:09 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 21 Apr 2015 14:08:09 +0200
Subject: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a
	fallback for migration
In-Reply-To: <55362751.3030609@oracle.com>
References: <8DFA52AB-8BA2-48C3-921F-B747307157CF@oracle.com>	<552D6B7D.8010107@oracle.com>
	<552E4D21.1070507@oracle.com>
	<84C8D355-FEA0-4C62-83AD-4F2C008A2500@oracle.com>
	<552E7745.40105@oracle.com>
	<0C0943A8-96B3-40A7-AD00-2C8D3284EFCA@oracle.com>
	<04397A3E-6940-47F5-A43A-16D07BC8FCFB@oracle.com>
	<55362751.3030609@oracle.com>
Message-ID: <5117DFD7-F588-46D4-87B8-6F80910A4FDB@oracle.com>


On Apr 21, 2015, at 12:32 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 
> 
> On 21/04/2015 11:20, Chris Hegarty wrote:
>> On 15 Apr 2015, at 16:43, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>>> On Apr 15, 2015, at 4:35 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>>> I marginally prefer using flatMap rather than map/filter e.g. change getHandler to return Stream< URLStreamHandler> and change the last line to be "return Stream.ofNullable(handle). Up to you.
>>>> That's better. For completeness, the updated webrev:
>>>> http://cr.openjdk.java.net/~chegar/8075139/webrev.03/
>> Argh! The launcher is now falling over with "Error occurred during initialization of VM?, in cases where a custom policy file contains a URL [*].
>> 

Oh well :-(

>> I?ll revert back to the version pre streams and lambda.
>> 
>> http://cr.openjdk.java.net/~chegar/8075139/webrev.01/
>> 
> This seems fine for now.
> 

Yes. 

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20150421/72525edc/signature.asc>

From Alan.Bateman at oracle.com  Tue Apr 21 13:56:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Apr 2015 14:56:14 +0100
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <1429551140.3444.39.camel@redhat.com>
References: <1429531333.3444.14.camel@redhat.com>	<1429532086.3444.15.camel@redhat.com>	<692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>
	<1429551140.3444.39.camel@redhat.com>
Message-ID: <553656FE.9000802@oracle.com>


On 20/04/2015 18:32, Severin Gehwolf wrote:
> :
> OK fixed:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.02/
>
> FWIW, I don't think the test needs IP addresses of DNS servers to be
> functional, though. All it really does is passing it to
> InetAddress.getByName(). Prior this patch DnsClient fails to parse the
> IP literals.
>
Can the test be moved to jdk/test/com/sun/jndi/dns as that seems to be 
where the other tests are? Also I assume this will need a copyright 
header before it is pushed.

-Alan

From michael.x.mcmahon at oracle.com  Tue Apr 21 15:04:04 2015
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 21 Apr 2015 16:04:04 +0100
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <553656FE.9000802@oracle.com>
References: <1429531333.3444.14.camel@redhat.com>	<1429532086.3444.15.camel@redhat.com>	<692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>	<1429551140.3444.39.camel@redhat.com>
	<553656FE.9000802@oracle.com>
Message-ID: <553666E4.8030908@oracle.com>

On 21/04/15 14:56, Alan Bateman wrote:
>
> On 20/04/2015 18:32, Severin Gehwolf wrote:
>> :
>> OK fixed:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.02/
>>
>> FWIW, I don't think the test needs IP addresses of DNS servers to be
>> functional, though. All it really does is passing it to
>> InetAddress.getByName(). Prior this patch DnsClient fails to parse the
>> IP literals.
>>
> Can the test be moved to jdk/test/com/sun/jndi/dns as that seems to be 
> where the other tests are? Also I assume this will need a copyright 
> header before it is pushed.
>
> -Alan

I had pushed it already. So, I'll fix it in this webrev

http://cr.openjdk.java.net/~michaelm/8078276/webrev.1/

Thanks,
Michael

From Alan.Bateman at oracle.com  Tue Apr 21 15:09:30 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Apr 2015 16:09:30 +0100
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <553666E4.8030908@oracle.com>
References: <1429531333.3444.14.camel@redhat.com>	<1429532086.3444.15.camel@redhat.com>	<692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>	<1429551140.3444.39.camel@redhat.com>
	<553656FE.9000802@oracle.com> <553666E4.8030908@oracle.com>
Message-ID: <5536682A.6070900@oracle.com>

On 21/04/2015 16:04, Michael McMahon wrote:
> On 21/04/15 14:56, Alan Bateman wrote:
>> :
>>>
>> Can the test be moved to jdk/test/com/sun/jndi/dns as that seems to 
>> be where the other tests are? Also I assume this will need a 
>> copyright header before it is pushed.
>>
>> -Alan
>
> I had pushed it already. So, I'll fix it in this webrev
>
> http://cr.openjdk.java.net/~michaelm/8078276/webrev.1/
Thanks.

-Alan.

From kubota.yuji at gmail.com  Tue Apr 21 15:31:54 2015
From: kubota.yuji at gmail.com (KUBOTA Yuji)
Date: Wed, 22 Apr 2015 00:31:54 +0900
Subject: Potential infinite waiting at JMXConnection#createConnection
Message-ID: <CABU-27M-b4eV+D2vbe4-=_KqspEXf9jdt_0isFbj06fPTufmww@mail.gmail.com>

Hi all,

I found an infinite waiting at TCPChannel#createConnection.
This method flushes the DataOutputStream without the socket timeout settings
when choose stream protocol [1].

If connection lost (the destination server do no return response)
during the flush,
this method has possibilities to take long time beyond the expectations
at java.net.SocketInputStream.socketRead0 as following stack trace.

stack trace :
        at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
        at java.net.SocketInputStream.read(SocketInputStream.java)
        at java.net.SocketInputStream.read(SocketInputStream.java)
        at sun.security.ssl.InputRecord.readFully(InputRecord.java)
        at sun.security.ssl.InputRecord.read(InputRecord.java)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java)
        at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java)
        at sun.security.ssl.AppOutputStream.write(AppOutputStream.java)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java)
        at java.io.DataOutputStream.flush(DataOutputStream.java)
        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java)
        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java)
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java)
        at javax.management.remote.rmi.RMIServerImpl_Stub.newClient
        at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java)
        at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java)
        at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java)

When create connection, we cannot set the timeout by properties.
Therefore, JMX sets
the default value of SO_TIMEOUT, i.e., infinite. So I wrote a patch to
fix this infinite
waiting by using property-configured value:
sun.rmi.transport.tcp.responseTimeout.

Please review this patch. :)

Note: My OCA has been processed a few hour ago, so my name may take a
short time to
appear on the OCA signatories page.

Thanks,
KUBOTA Yuji

[1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191

diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
--- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
+++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
@@ -222,20 +222,34 @@
                 // choose protocol (single op if not reusable socket)
                 if (!conn.isReusable()) {
                     out.writeByte(TransportConstants.SingleOpProtocol);
                 } else {
                     out.writeByte(TransportConstants.StreamProtocol);
+
+                    int usableSoTimeout = 0;
+                    try {
+                        /*
+                         * If socket factory had set a zero timeout on its own,
+                         * then set the property-configured value to prevent
+                         * an infinite waiting.
+                         */
+                        usableSoTimeout = sock.getSoTimeout();
+                        if (usableSoTimeout == 0) {
+                          usableSoTimeout = responseTimeout;
+                        }
+                        sock.setSoTimeout(usableSoTimeout);
+                    } catch (Exception e) {
+                        // if we fail to set this, ignore and proceed anyway
+                    }
                     out.flush();

                     /*
                      * Set socket read timeout to configured value for JRMP
                      * connection handshake; this also serves to guard against
                      * non-JRMP servers that do not respond (see 4322806).
                      */
-                    int originalSoTimeout = 0;
                     try {
-                        originalSoTimeout = sock.getSoTimeout();
                         sock.setSoTimeout(handshakeTimeout);
                     } catch (Exception e) {
                         // if we fail to set this, ignore and proceed anyway
                     }

@@ -279,18 +293,11 @@
                      * connection.  NOTE: this timeout, if configured to a
                      * finite duration, places an upper bound on the time
                      * that a remote method call is permitted to execute.
                      */
                     try {
-                        /*
-                         * If socket factory had set a non-zero timeout on its
-                         * own, then restore it instead of using the property-
-                         * configured value.
-                         */
-                        sock.setSoTimeout((originalSoTimeout != 0 ?
-                                           originalSoTimeout :
-                                           responseTimeout));
+                        sock.setSoTimeout(usableSoTimeout);
                     } catch (Exception e) {
                         // if we fail to set this, ignore and proceed anyway
                     }

                     out.flush();

From Alan.Bateman at oracle.com  Wed Apr 22 06:56:15 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 22 Apr 2015 07:56:15 +0100
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <553666E4.8030908@oracle.com>
References: <1429531333.3444.14.camel@redhat.com>	<1429532086.3444.15.camel@redhat.com>	<692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>	<1429551140.3444.39.camel@redhat.com>
	<553656FE.9000802@oracle.com> <553666E4.8030908@oracle.com>
Message-ID: <5537460F.7030201@oracle.com>

On 21/04/2015 16:04, Michael McMahon wrote:
> :
>
> http://cr.openjdk.java.net/~michaelm/8078276/webrev.1/
Before you push this, shouldn't the test have copyright Red Hat? There's 
an example in the same directory.

-Alan

From sgehwolf at redhat.com  Wed Apr 22 08:39:55 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 22 Apr 2015 10:39:55 +0200
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <5536682A.6070900@oracle.com>
References: <1429531333.3444.14.camel@redhat.com>
	<1429532086.3444.15.camel@redhat.com>
	<692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>
	<1429551140.3444.39.camel@redhat.com> <553656FE.9000802@oracle.com>
	<553666E4.8030908@oracle.com> <5536682A.6070900@oracle.com>
Message-ID: <1429691995.3491.2.camel@redhat.com>

On Tue, 2015-04-21 at 16:09 +0100, Alan Bateman wrote:
> On 21/04/2015 16:04, Michael McMahon wrote:
> > On 21/04/15 14:56, Alan Bateman wrote:
> >> :
> >>>
> >> Can the test be moved to jdk/test/com/sun/jndi/dns as that seems to 
> >> be where the other tests are? Also I assume this will need a 
> >> copyright header before it is pushed.
> >>
> >> -Alan
> >
> > I had pushed it already. So, I'll fix it in this webrev
> >
> > http://cr.openjdk.java.net/~michaelm/8078276/webrev.1/

Thanks Michael, for sponsoring and then moving the test!

Cheers,
Severin




From gnu.andrew at redhat.com  Wed Apr 22 21:45:58 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 22 Apr 2015 17:45:58 -0400 (EDT)
Subject: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws
	NumberFormatException
In-Reply-To: <5537460F.7030201@oracle.com>
References: <1429531333.3444.14.camel@redhat.com>
	<1429532086.3444.15.camel@redhat.com>
	<692561968.2911058.1429547064809.JavaMail.zimbra@redhat.com>
	<1429551140.3444.39.camel@redhat.com>
	<553656FE.9000802@oracle.com> <553666E4.8030908@oracle.com>
	<5537460F.7030201@oracle.com>
Message-ID: <674681858.4662733.1429739158203.JavaMail.zimbra@redhat.com>



----- Original Message -----
> On 21/04/2015 16:04, Michael McMahon wrote:
> > :
> >
> > http://cr.openjdk.java.net/~michaelm/8078276/webrev.1/
> Before you push this, shouldn't the test have copyright Red Hat? There's
> an example in the same directory.
> 
> -Alan
> 

Yes, I was thinking the same just now.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07