RE: RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris
Hi Vyom,
thanks for looking at this. Overall your fix and test look good to me.
The coding to do the parent search and if required a child search in
Java_java_net_NetworkInterface_getByName0 could be done a bit more
straightforward, e.g. like this:
// search the list of interfaces by name
// for virtual interfaces we need to find the parent first
colonp = strchr(name_utf, ':');
if (colonp == NULL) {
searchName = name_utf;
} else {
jio_snprintf(pname, IFNAMESIZE, "%.*s", colonp - name_utf);
searchName = pname;
}
curr = ifs;
while (curr != NULL) {
if (strcmp(searchName, curr->name) == 0) {
break;
}
curr = curr->next;
}
// search the child list
if (curr != NULL && colonp != NULL) {
curr = curr->childs;
while (curr != NULL) {
if (strcmp(name_utf, curr->name) == 0) {
break;
}
curr = curr->next;
}
}
Best regards
Christoph
> -Original Message-
> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Vyom
> Tewari
> Sent: Dienstag, 13. Dezember 2016 04:47
> To: net-dev
> Subject: RFR 8168840: InetAddress.getByName() throws
> java.net.UnknownHostException no such interface when used with virtual
> interfaces on Solaris
>
> Hi,
>
> Please review the code changes for below issue.
>
> BugId: https://bugs.openjdk.java.net/browse/JDK-8168840
>
> webrev :
> http://cr.openjdk.java.net/~vtewari/8168840/webrev0.0/index.html
>
>
> Thanks,
>
> Vyom
RE: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for network channels on MacOS
Hi Michael, given the recent changes that were submitted (jigsaw update, aot) I don't think Christoph's changes can be considered a major risk. They have been worked on for quite a while now, and they are tested well on our side. So I really would appreciate if they could be submitted as-is. Reworking them into smaller changes can introduce new issues and will delay the push of the changes further. I especially would like to see 8170544 finding its way into jdk9. Best regards, Goetz. > -Original Message- > From: Langer, Christoph > Sent: Dienstag, 13. Dezember 2016 10:54 > To: Lindenmaier, Goetz > Subject: FW: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for > network channels on MacOS > > > > -Original Message- > From: Michael McMahon [mailto:michael.x.mcma...@oracle.com] > Sent: Freitag, 9. Dezember 2016 17:19 > To: Langer, Christoph > Cc: Chris Hegarty ; OpenJDK Network Dev list > > Subject: Re: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for > network channels on MacOS > > Those suggestions are reasonable Christoph. I think given the subtle > nature of the bug > (removing the #include not causing a compile error) I'm a bit wary about > pushing wide scale > native code changes at this stage of JDK 9. We might therefore defer the > other cleanups until 10 > opens up in the new year. > > Michael. > > On 09/12/2016, 11:16, Langer, Christoph wrote: > > Hi Michael, > > > > the bug then obviously was a side effect of my change > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9f0ab4b20ff7 for 8167481. Sorry > for that. > > > > To follow the concept of my cleanups I'd prefer if you could use #if > defined(MACOSX) rather than #ifdef MACOSX in net_util_md.c to be consistent > within the file. > > > > I also followed the platform order 1. Linux, 2. AIX, 3. Solaris, 4. Mac in > > all > parts of the native code, so your newly introduced section should go after the > "#if defined(__solaris__)" system header include parts, e.g. line 47 of the > original file. > > > > Thanks > > Christoph > > > >> -Original Message- > >> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of > Chris > >> Hegarty > >> Sent: Freitag, 9. Dezember 2016 11:52 > >> To: Michael McMahon; OpenJDK > Network > >> Dev list > >> Subject: Re: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for > >> network channels on MacOS > >> > >> > >> On 09/12/16 10:33, Michael McMahon wrote: > >>> Could I get the following change reviewed please? > >>> > >>> http://cr.openjdk.java.net/~michaelm/8170920/webrev.1/ > >> Looks good. > >> > >> You may just want to remove the "from" year from the copyright > >> year range in the test, before pushing. > >> > >> -Chris.
Re: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for network channels on MacOS
Hi Goetz, Christoph has already done the work to split these changes into smaller chunks, 8171075 and 8171077. He has reviews out, and they are on my list to get to in the next few days. If it is ok, I’d like to proceed with this as is, form an initial skim they appear easier to review. -Chris. > On 13 Dec 2016, at 10:14, Lindenmaier, Goetz > wrote: > > Hi Michael, > > given the recent changes that were submitted (jigsaw update, aot) > I don't think Christoph's changes can be considered a major risk. > They have been worked on for quite a while now, and they are > tested well on our side. > So I really would appreciate if they could be submitted as-is. > Reworking them into smaller changes can introduce new issues > and will delay the push of the changes further. > I especially would like to see 8170544 finding its way into jdk9. > > Best regards, > Goetz. > >> -Original Message- >> From: Langer, Christoph >> Sent: Dienstag, 13. Dezember 2016 10:54 >> To: Lindenmaier, Goetz >> Subject: FW: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for >> network channels on MacOS >> >> >> >> -Original Message- >> From: Michael McMahon [mailto:michael.x.mcma...@oracle.com] >> Sent: Freitag, 9. Dezember 2016 17:19 >> To: Langer, Christoph >> Cc: Chris Hegarty ; OpenJDK Network Dev list >> >> Subject: Re: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for >> network channels on MacOS >> >> Those suggestions are reasonable Christoph. I think given the subtle >> nature of the bug >> (removing the #include not causing a compile error) I'm a bit wary about >> pushing wide scale >> native code changes at this stage of JDK 9. We might therefore defer the >> other cleanups until 10 >> opens up in the new year. >> >> Michael. >> >> On 09/12/2016, 11:16, Langer, Christoph wrote: >>> Hi Michael, >>> >>> the bug then obviously was a side effect of my change >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9f0ab4b20ff7 for 8167481. Sorry >> for that. >>> >>> To follow the concept of my cleanups I'd prefer if you could use #if >> defined(MACOSX) rather than #ifdef MACOSX in net_util_md.c to be consistent >> within the file. >>> >>> I also followed the platform order 1. Linux, 2. AIX, 3. Solaris, 4. Mac in >>> all >> parts of the native code, so your newly introduced section should go after >> the >> "#if defined(__solaris__)" system header include parts, e.g. line 47 of the >> original file. >>> >>> Thanks >>> Christoph >>> -Original Message- From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of >> Chris Hegarty Sent: Freitag, 9. Dezember 2016 11:52 To: Michael McMahon; OpenJDK >> Network Dev list Subject: Re: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for network channels on MacOS On 09/12/16 10:33, Michael McMahon wrote: > Could I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/8170920/webrev.1/ Looks good. You may just want to remove the "from" year from the copyright year range in the test, before pushing. -Chris.
RFR 8038079: Re-examine integration of SPNEGO authentication
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 uses different authentication schemes. Among others there's a scheme called SPNEGO, which is defined in a different module, java.security.jgss Thanks, -Pavel [1] https://bugs.openjdk.java.net/browse/JDK-8038079
Re: RFR 8038079: Re-examine integration of SPNEGO authentication
On 13 Dec 2016, at 12:28, Pavel Rappo wrote: > > Hello, > > Could you please review the following change for [1]? > >http://cr.openjdk.java.net/~prappo/8038079/webrev.00/ Looks good. Maybe just a short comment in the module-info.class? // to support SPNEGO from HttpURLConnection -Chris.
