Greetings:
Please consider the following socket constructor changes:
http://cr.openjdk.java.net/~jzavgren/8017079/webrev.01/
<http://cr.openjdk.java.net/%7Ejzavgren/8017079/webrev.01/>
Thanks!
John
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
.
- Kurchi
[1]
http://cr.openjdk.java.net/~arieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html
<http://cr.openjdk.java.net/%7Earieber/6563286/webrev.00/test/sun/net/www/http/HttpURLConnection/MalformedFollowRedirect.java.html>
On 6/26/
s
John
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
}
}
class TestCookieHandler extends CookieHandler {
@Override
public Map> get(URI uri, MapList> requestHeaders) {
return new HashMap>();
}
@Override
public void put(URI uri, Map> responseHeaders) {
}
}
-
-Chris.
On 06/19/2013 04:27 PM, John Zavgren wro
; receptions.
http://cr.openjdk.java.net/~jzavgren/8014377/webrev.03/
<http://cr.openjdk.java.net/%7Ejzavgren/8014377/webrev.03/>
Thanks!
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
/cr.openjdk.java.net/~jzavgren/8014499/webrev.04/
<http://cr.openjdk.java.net/%7Ejzavgren/8014499/webrev.04/>
Thanks!
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
/8015799/webrev.01/>
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
"SocketException",
"Unable to set SO_BROADCAST");
return; <<< setsockopt() failed, we threw an exception. We
didn't close the socket.
}
--
John Zavgren
john.zavg...@oracle.com
603-821-0904
US-Burlington-MA
All:
I have a revised webrev image that's ready for review:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.04/
Thanks
John
On 05/13/2013 04:14 PM, John Zavgren wrote:
Greetings:
I posted a new webrev image:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.03/
that fixes a memory
All:
I'd like to give everyone another chance to weigh in on this change:
http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/
so that I can wrap up this fix ASAP.
(It makes HTTP cookies that begin with a dollar sign "illegal".)
Thanks!
John
On 05/15/2013 07:54 AM, Joh
Greetings:
Can I get a show of hands on this RFR
(http://cr.openjdk.java.net/~jzavgren/7188517/webrev.04/)?
It's CCC request has been accepted and I'd like to wrap it up ASAP.
Thanks!
John Zavgren
On 05/09/2013 02:22 PM, John Zavgren wrote:
Greetings:
I made a mistake in my last R
rrors in
other files in the same directory as the two previously mentioned files.
On 03/04/2013 01:17 PM, Chris Hegarty wrote:
On 03/04/2013 04:28 PM, John Zavgren wrote:
Greetings:
I've posted a webrev image of a memory leak fix:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/
cookie
names that lead with a dollar sign.
I'm sorry about the confusion.
Thanks!
John
On 05/09/2013 03:42 PM, John Zavgren wrote:
> Chris, et alia:
> I put the reinstated the old test.
> http://cr.openjdk.java.net/~jzavgren/7188517/webrev.03/
>
> John
>
> - Ori
ion if the IllegalArgumentException is not
> obtained, otherwise the test looses its
> purpose, and will pass silently if someone mistakenly removes the $
> check in our code.
>
> - Kurchi
>
> On 5/8/2013 12:10 PM, John Zavgren wrote:
>> Greetings:
>>
>>
k8/jdk/rev/7bd32bfc0539
- Kurchi
On 5/2/2013 10:09 AM, John Zavgren wrote:
All:
My original email was mangled by my email program (stbeehive/zimbra)
... so I'm sending a second correctly formatted copy.
I'm sorry for the inconvenience.
John
---
Please consider the fol
SO_BINDTODEVICE can be used in cases where an IP network application doesn't
want the existing routing table entries to determine the interface that packets
are transmitted from. This is often the case when one is writing a router that
needs to do neighbor discovery. I used this extensively a fe
document (notice the specdiff:
http://cr.openjdk.java.net/~jzavgren/7188517/specDiff/ ) prohibited the use of
cookie names that are one of the tokens reserved for use by the cookie
protocol, and this restriction is not necessary.
Thanks!
John Zavgren
- Original Message -
From: john.za
riction is not necessary.
Thanks!
John Zavgren
Greetings:
I've cleaned up some formatting nits and a leak that I created in my
realloc() "repairs" and created a revised webrev image:
http://cr.openjdk.java.net/~jzavgren/8012108/webrev.04
John
On 04/24/2013 09:10 PM, John Zavgren wrote:
All:
I expanded the scope of th
redundant.
438 - we will crash here if start is null
Maybe it is good to have an additional check for start != null, but from what I
see, start will not be null if *netaddrPP is not null.
-Dmitry
On 2013-04-20 01:33, John Zavgren wrote:
Greetings:
I fixed the bad realloc pattern. Please
rote:
On Apr 20, 2013, at 3:16 AM, Dmitry Samersoff
wrote:
John,
102, 145 else is redundant.
438 - we will crash here if start is null
Maybe it is good to have an additional check for start != null, but from what I
see, start will not be null if *netaddrPP is not null.
-Dmitry
O
gt; e.g.
>
> 93 adapterInfo = (IP_ADAPTER_ADDRESSES *) realloc (adapterInfo, len);
>
> -Dmitry
>
> On 2013-04-19 00:56, John Zavgren wrote:
>> Greetings:
>>
>> I fixed a case in the windows native code where calloc() was being used
>> without checking it's retu
Greetings:
I fixed a case in the windows native code where calloc() was being used without
checking it's returned value.
http://cr.openjdk.java.net/~jzavgren/8012108/webrev.01/
Thanks!
John Zavgren
Greetings:
Please review the following webrev image. I fixed a memory leak that can occur
when calloc() fails.
http://cr.openjdk.java.net/~jzavgren/8012108/webrev.01/
Thanks!
John Zavgren
john.zavg...@oracle.com
://www.ietf.org/rfc/rfc2617.txt) section 3.2.2
and follow its references back to section 3.2.1
http://cr.openjdk.java.net/~jzavgren/8010505/webrev.01/
Thanks!
John Zavgren
PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8008804
On 04/03/2013 19:37, John Zavgren wrote:
> Thanks for catching that Dmitry. I just posted a new webrev image for a
> change that uses the correct procedure:
> http://cr.openjdk.java.net/~jzavgren/8008804/webrev.02/
>
> J
Sent: Monday, March 4, 2013 12:59:16 PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8008804
John,
closesocket call should be here.
-Dmitry
On 2013-03-04 20:12, John Zavgren wrote:
> Greetings:
>
> I posted a webrev image for a modification that eliminates a file descriptor
> lea
hn.zavg...@oracle.com
Sent: Monday, March 4, 2013 1:17:31 PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8008972
On 03/04/2013 04:28 PM, John Zavgren wrote:
> Greetings:
>
> I've posted a webrev image of a memory leak fix:
> http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/
Greetings:
I've posted a webrev image of a memory leak fix:
http://cr.openjdk.java.net/~jzavgren/8008972/webrev.01/
Thanks!
John
Greetings:
I posted a webrev image for a modification that eliminates a file descriptor
leak.
http://cr.openjdk.java.net/~jzavgren/8008804/webrev.01/
Thanks!
John
Greetings:
I fixed numerous errors that were identified by Mr. Davidovich.
I've posed a new webrev image at:
http://cr.openjdk.java.net/~jzavgren/8007606/webrev.02/
<http://cr.openjdk.java.net/%7Ejzavgren/8007606/webrev.02/>
Thanks!
John Zavgren
On 02/05/2013 07:33 PM, Vitaly
Greetings:
I modified the use of malloc() and realloc() so that return values are checked
and potential memory leaks and data corruption problems are prevented.
http://cr.openjdk.java.net/~jzavgren/8007606/webrev.01/
Thanks!
John Zavgren
fields.
---
> * Only classes derived from URLStreamHandler are able to use this
> * method to set the values of the URL fields.
It is still not great, but I think the best we can do with an old API.
-Chris.
On 04/02/2013 14:00, John Zavgren wrote:
> I posted a new webrev image:
> htt
I posted a new webrev image:
http://cr.openjdk.java.net/~jzavgren/4880778/webrev.02/
I made two changes:
1.) modified the indentation that's used for the argument list of the URL class
set() methods.
2.) changed the documentation for the set method in the URLStreamHandler class.
- Original
Greetings:
Please consider the following modification of our classes for handling URLs.
http://cr.openjdk.java.net/~jzavgren/4880778/webrev.01/
background
See http://java.sun.com/j2se/1.4.2/docs/api/java/net/URL.html.
The URL class is declared final yet has two protected methods:
prot
.openjdk.java.net/~jzavgren/8005120/webrev.07/
<http://cr.openjdk.java.net/%7Ejzavgren/8005120/webrev.07/>
Thank you!
John Zavgren
john.zavg...@oracle.com
On 12/20/2012 05:47 PM, John Zavgren wrote:
Greetings:
I modified my changes so that windows knows the definition of the POSIX data
On 12/28/2012 10:49 AM, John Zavgren wrote:
Please consider the following webrev for JDK-8005120.
http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.06/
(I apologize for overlooking an error in the windows code that I created in my
previous release. )
Thanks!
John Zavgren
Greetings:
I modified windows source code files so they pass size_t for buffer
sizes and socklen_t for address structures.
http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.03/
Please let me know what you think.
Thanks!
On 12/26/2012 02:56 PM, John Zavgren wrote
Greetings:
I modified the windows code so that it uses socklen_t to specify the
lengths of data structures, parameter lengths, etc. instead of ints
(which can be negative.)
http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.02/
Thanks!
John Zavgren
On 12/20/2012 05:47 PM
1/
Thanks!
John Zavgren
On 20/12/2012 13:49, John Zavgren wrote:
> Greetings:
>
> I agree that the "correct" way to fix this problem is to use POSIX data
> types, e.g., socklen_t. However, when I switch to the doctrinaire data type,
> the build fails on windows machin
r-sign]
>> ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected
>> 'uint32_t *' but argument is of type 'int *'
>>
>> Do you see these in your build?
>>
>> -Chris.
>>
>> On 12/19/2012 03:42 PM, Alan Bateman wrote:
>
GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8005120
John,
On 2012-12-19 22:25, John Zavgren wrote:
> Yes... I did consider that, but I didn't see any POSIX data types near the
> code I was changing, so I decided to use a "brute force" data type instead.
connect, recvfr
com
Cc: net-dev@openjdk.java.net
Sent: Wednesday, December 19, 2012 1:06:52 PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8005120
John,
Did you consider using socklen_t instead of uint32_t and unsigned int
(for namelen etc) ?
-Dmitry
On 2012-12-19 19:36, John Zavgren wrote:
> Greetings:
>
correctly. They were declared as integers, but they must be "unsigned" integers
because they are used to define buffer lengths. Were one to supply a negative
value as an argument, it would be cast into an unsigned "Martian" value and
there'd be (hopefully) a system call err
hat.)
>
> http://cr.openjdk.java.net/~mullan/webrevs/8003991/webrev.00/
>
> Thanks!
> John Zavgren
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
/webrev.00/
Thanks!
John Zavgren
2012 2:49:46 PM GMT -05:00 US/Canada Eastern
Subject: RFR JDK-80003991
Greetings:
The procedure initLoopbackRoutes() has a file descriptor leak.
http://cr.openjdk.java.net/~mullan/webrevs/8003991/
Thanks!
John Zavgren
Greetings:
The procedure initLoopbackRoutes() has a file descriptor leak.
http://cr.openjdk.java.net/~mullan/webrevs/8003991/
Thanks!
John Zavgren
I see after reading the correspondence that DNS would be used to bind the names
to the numbers, as in RFC 2728 :http://www.dns-sd.org/ServiceTypes.html.
(There is a convenient description here:
http://en.wikipedia.org/wiki/SRV_record.)
I wasn't aware of this effort. It's very cool and useful, e
Max:
I've never seen a procedure that binds a protocol to a port number. (The http
protocol you mention usually uses TCP port number 80, but the port choice for
this protocol is up to the discretion of the programmer. The file /etc/services
binds names to numbers so that tools like tcpdump and n
urchi
On 24.10.2012 06:27, Chris Hegarty wrote:
> Looks good to me. Thanks for going the extra mile here.
>
> -Chris.
>
> On 24/10/2012 14:16, John Zavgren wrote:
>>
>> Greetings:
>>
>> I'm requesting a review of a software change that fixes a file
>&g
Greetings:
I'm requesting a review of a software change that fixes a file descriptor leak
AND a potential memory leak that involves memory reallocation (realloc()). The
webrev image is in the following location:
http://cr.openjdk.java.net/~chegar/8000203/webrev.01/
Thanks!
John Za
Greetings:
I'm requesting a review of a proposed change that fixes a file descriptor leak.
The webrev image is in the following location:
http://cr.openjdk.java.net/~chegar/8000203/webrev.00/
Thanks!
John Zavgren
john.zavg...@oracle.com
esn't change any of the externally-visible behavior in the procedure.
I look forward to your comments and suggestions.
Thanks!
John Zavgren
john.zavg...@oracle.com
Yes, this seems reasonable to me too. There seem to be fewer and fewer
applications that use ftp...
- Original Message -
From: chris.hega...@oracle.com
To: alan.bate...@oracle.com
Cc: net-dev@openjdk.java.net
Sent: Monday, October 15, 2012 2:48:05 PM GMT -05:00 US/Canada Eastern
Subject: R
a bug. I assume it's
better to put minor harmless tweaks in our code than to add state information
to parfait, that would cause it to ignore certain "situations". That option
seems complicated and dangerous.
Thanks!
John Zavgren
john.zavg...@oracle.com
field name to be set is "imr_address",
whereas when other OSes are used, the field name is: imr_interface.
Am I understanding your suggestion correctly?
Thanks!
John
-Dmitry
On 2012-09-14 22:22, John Zavgren wrote:
> Greetings:
>
>
> This bug (7193520) was filed beca
.
PlainDatagramSocketImpl.c
318 brackets is not necessary anymore
1644 whole #ifdef could be removed
struct ip_mreqn mreqn;
is not necessary anymore,
2283 the same
2294 #ifdef is not necessary anymore
-Dmitry
On 2012-09-14 22:22, John Zavgren wrote:
> Greetings:
>
>
the run time checks
are eliminated.
Thanks!
and
RSVP
John Zavgren
john.zavg...@oracle.com
equently whenever I make something, the very first step is to format the
code, and I know that when I do a check in later on... I never have to think
about whether or not the code conforms to a style guide... because the options
I gave to "indent" implemented this guide. (You can do similar
Kurchi:
That is a mistake.
I'll change the HTTPS name right now... and create a new webrev image.
Thanks!
John Zavgren
- Original Message -
From: kurchi.subhra.ha...@oracle.com
To: john.zavg...@oracle.com
Cc: net-dev@openjdk.java.net
Sent: Wednesday, September 5, 2012 11:54:01 A
rver should be named TestHttpsServer to be similar
to the Http equivalent. Otherwise, it looks fine to me.
And I think we'll look into migrating these tests to use the
com.sun.net.httpserver
API instead of that old implementation in the test tree.
Thanks
Michael
On 05/09/12 15:39, John Z
ision". The server in the test code
(which is intended to be used ONLY for testing) has the same name as the server
that's used as an actual Http Server:
./jdk/src/share/classes/com/sun/net/httpserver/HttpServer.java
Thanks,
John Zavgren
63 matches
Mail list logo