Changeset: 495ba30cf02f
Author:chegar
Date: 2010-04-06 15:44 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/495ba30cf02f
692: NullPointerException in PlainDatagramSocketImpl.socketSetOption
Reviewed-by: alanb
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/
Changeset: 69002275e0e2
Author:chegar
Date: 2010-04-06 13:47 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69002275e0e2
6648001: Cancelling HTTP authentication causes subsequent deadlocks
Reviewed-by: michaelm
! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo
On 03/26/10 13:45, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi Michael, Alan,
This is a very small change to fix a problem in native code where, if
multiple threads are executing the native method, an unset value of a
static variable may be used. When setting
Hi Michael, Alan,
This is a very small change to fix a problem in native code where, if
multiple threads are executing the native method, an unset value of a
static variable may be used. When setting static variables in a block we
can only be sure they are all set when the last one is. This is
Hi Michael,
This is a forward port of a fix that you put in 6uXX.
By exposing the key used in the authentication cache outside of
AuthenticationInfo, this allows all requests to be terminated correctly,
including ones, that have no username/password returned.
Webrev:
http://cr.openjdk.java
Changeset: 6109b166bf68
Author:chegar
Date: 2010-03-25 09:38 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6109b166bf68
6937703: java/net regression test issues with samevm
Reviewed-by: alanb
! test/ProblemList.txt
! test/java/net/ProxySelector/B6737819.java
! test/java/net
On 24/03/2010 11:46, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
:
Thanks Alan,
I've made the changes you suggested and updated the webrev.
Good okay to me. In passing I see HttpTest.run also silently consumes
any exceptions so you might want to do this whil
On 24/03/2010 11:06, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi Michael, Alan,
Some more test updates for samevm mode.
Webrev:
http://cr.openjdk.java.net/~chegar/6937703/webrev.00/webrev/
-Chris.
In HttpTest.java I see exceptions are silently consumed
Hi Michael, Alan,
Some more test updates for samevm mode.
Webrev:
http://cr.openjdk.java.net/~chegar/6937703/webrev.00/webrev/
-Chris.
Changeset: 8a9ebdc27045
Author:chegar
Date: 2010-03-23 13:54 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8a9ebdc27045
6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all
its Sockets
6771432: createSocket() - smpatch fails using 1.6.0_10 because
Dooh! Webrev:
http://cr.openjdk.java.net/~chegar/6614957/webrev.00/webrev/
-Chris.
On 22/03/2010 16:01, Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi Andrew, Michael,
This review is to forward port the following three bugs from 6uXX to JDK7:
6614957: HttpsURLConnection not using
Hi Andrew, Michael,
This review is to forward port the following three bugs from 6uXX to JDK7:
6614957: HttpsURLConnection not using the set SSLSocketFactory for
creating all its Sockets
6771432: createSocket() - smpatch fails using 1.6.0_10 because of
"Unconnected socke
Changeset: c40572afb29e
Author:chegar
Date: 2010-03-22 11:55 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c40572afb29e
6632169: HttpClient and HttpsClient should not try to reverse lookup IP address
of a proxy server
Reviewed-by: michaelm
! src/share/classes/sun/net/www/p
jdk.java.net/~chegar/6706251/webrev.00/webrev/
-Chris.
On 19/03/2010 15:33, Andrew John Hughes wrote:
On 19 March 2010 15:12, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
:
I vaguely remember the history of this issue (Michael will know better),
but the expectation
On 19/03/2010 15:04, Michael McMahon wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
On 19/03/2010 14:42, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi Michael,
This is a forward port of a fix that you did in JDK6u11 to JDK7. The
source changes are
On 19/03/2010 14:42, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi Michael,
This is a forward port of a fix that you did in JDK6u11 to JDK7. The
source changes are trivial and the very same as what went in 6.
The change is for strict conformance of
Hi Michael,
This is a forward port of a fix from JDK6u6 to JDK7. The source changes
are small and the very same as what went in 6.
The HttpClient was changed to use getHostString (does not perform
reverse lookup), but the HttpsClient was overlooked at the time. This
fix changes the HttpsClie
Hi Michael,
This is a forward port of a fix that you did in JDK6u11 to JDK7. The
source changes are trivial and the very same as what went in 6.
The change is for strict conformance of getDisplayName, should return
null instead of an empty string.
Webrev:
http://cr.openjdk.java.net/~chega
Changeset: 3bb93c410f41
Author:chegar
Date: 2010-03-19 13:07 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3bb93c410f41
6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with
modules build
Reviewed-by: alanb
! test/ProblemList.txt
! test/java/net/Serv
Andrew John Hughes wrote:
On 18 March 2010 20:56, Christopher Hegarty -Sun Microsystems Ireland
wrote:
Brad, Pavel, Andrew,
I'm also not comfortable with this test, but what bothers me more than the
reliance on an external server is the reliance on cacerts. While cacerts (or
equivalen
uments/913/147490 seems an
appropriate URL to hit. It's the very URL that causes the OpenJDK
build to fail to bootstrap itself and I assume Oracle do control
dev.java.net to some degree.
Brad
On 3/18/2010 8:50 AM, Pavel Tisnovsky wrote:
Christopher Hegarty -Sun Microsystems Ireland
Sean Mullan wrote:
Security folk:
Do we currently have any tests with a dependency on cacerts?
yes, but they would be in the closed tests.
So we have your own non public tests for this. Maybe RedHat should take
a similar approach then.
-Chris.
--Sean
Pavel Tisnovsky wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Alan Bateman wrote:
Pavel Tisnovsky wrote:
Hi,
please review new regression test for java.net.* API. This test
check if the cacerts keytool database is configured properly and SSL
is really working. The test should
Alan Bateman wrote:
Pavel Tisnovsky wrote:
Hi,
please review new regression test for java.net.* API. This test check
if the cacerts keytool database is configured properly and SSL is
really working. The test should not fail if SSL is working (in other
case it simply throws IOException). Webr
Alan Bateman wrote:
It still seems very fragile and doesn't take into account that the
number of file descriptors might legitimately increase. How about
changing the test to use ulimit on Solaris/Linux to set the hard limit
to a smallish limit (say 1024) and then run and accept >1024
co
Alan, Michael,
java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with
modules build because number of open file descriptors exceeds 20.
Instead of a hardcoded number, the test should check the number of file
descriptors does not increase much before and after its work.
Also, run
Changeset: 895a1211b2e1
Author:chegar
Date: 2010-03-16 14:31 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/895a1211b2e1
6935199: java/net regression tests failing with Assertions
Reviewed-by: michaelm
! test/ProblemList.txt
! test/java/net/CookieHandler/TestHttpCookie.java
Michael McMahon wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Michael McMahon wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Hi Michael,
The following tests have incorrect assertion failures if run with
assertions enabled:
test/java/net/CookieHandler
Michael McMahon wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Hi Michael,
The following tests have incorrect assertion failures if run with
assertions enabled:
test/java/net/CookieHandler/TestHttpCookie.java
Would it be better to just remove the assertion in the first one
Hi Michael,
The following tests have incorrect assertion failures if run with
assertions enabled:
test/java/net/CookieHandler/TestHttpCookie.java
test/java/net/URLClassLoader/closetest/CloseTest.java
Webrev:
http://cr.openjdk.java.net/~chegar/6935199/webrev.00/webrev/
-Chris.
Changeset: f88f6f8ddd21
Author:chegar
Date: 2010-03-16 10:05 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f88f6f8ddd21
6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10
Reviewed-by: alanb
! test/java/net/ipv6tests/TcpTest.java
! test/java/net/ipv6tests/Test
Hi Alan, Michael,
The test has a connected TCP socket and performs individual writes of
only 2 bytes on one end. It does not read off the data on the other end.
After 8 writes, on the 9th, the write blocks. Clearly the send buffer
has not been exhausted, but after some experimenting it can be
ad, and we don't
provide any NAT traversal support for server sockets and datagram
sockets using UPnP's IGD or Bonjour's NAT-PMP protocols. Maybe we
should?
Damjan
On Wed, Mar 3, 2010 at 3:55 PM, Christopher Hegarty -Sun Microsystems
Ireland wrote:
Hi Damjan,
After spending mor
Changeset: c6f8c58ed51a
Author:chegar
Date: 2010-03-11 17:50 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6f8c58ed51a
6223635: Code hangs at connect call even when Timeout is specified when using a
socks proxy
Reviewed-by: michaelm, chegar
Contributed-by: damjan@gmail
Changeset: c342735a3e58
Author:chegar
Date: 2010-03-11 17:37 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c342735a3e58
6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in
samevm mode
Reviewed-by: alanb
! test/ProblemList.txt
! test/java/net/CookieHan
Michael McMahon wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Hi All,
This patch fixes a problem where the socks proxy implementation does
not honor the timeout specified in Socket.connect(SocketAddress,
timeout). In fact, it uses the read timeout set with setSoTimeout
since
Changeset: 07e1c5a90c6a
Author:chegar
Date: 2010-03-11 16:17 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07e1c5a90c6a
6934054: java/net/Socket/FDClose.java return error in samevm
Summary: test is no longer useful
Reviewed-by: alanb
! test/ProblemList.txt
- test/java/net/S
Alan Bateman wrote:
.
I'm tempted to suggest that the best thing is to just hg rm the test as
it's not very useful. If you want to keep it then the changes looks OK
This had crossed my mind. If you agree then I think I will just remove it.
-Chris.
to me. One suggestion is to have ARea
Hi Alan, Michael,
Another small test change!
This test requires interruptible I/O to verify that the accept
implementation does not impact on fd0. UseVMInterruptibleIO needs to be
explicitly enabled since it is now disabled by default, see 6554406.
Without interruptible I/O the thread executi
On 10/03/2010 17:34, Alan Bateman wrote:
...
Looks OK to me. Don't forget to remove it from test/ProblemList.txt.
Ah yes, good call. I'll remove it and do a few jprt runs before pushing.
Thanks,
-Chris.
-Alan.
Hi Alan, Michael,
Summary: Make test run in othervm.
java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm
mode with a NullPointer Exception cause by
CookieHandlerTest$MyCookieHandler.put(CookieHandlerTest.java:131)
The CookieHandlerTest$MyCookieHandler the HTTP protocol ha
Changeset: 47958f76babc
Author:chegar
Date: 2010-03-10 14:44 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47958f76babc
6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun
Reviewed-by: alanb
! test/java/net/MulticastSocket/NoLoopbackPackets.java
On 10/03/2010 12:32, Alan Bateman wrote:
..
Looks okay to me - one small suggestion is to close msock in a finally
block so that the file descriptor usage doesn't creep up during these
samevm runs.
Ah, good catch! Webrev updated.
Thanks,
-Chris.
-Alan.
Hi Alan, Michael,
Trivial change.
6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun
If java/net/MulticastSocket/NoLoopbackPackets.java is run in a batch
which contains all the MulticastSocket tests then it will fail on reruns
with java.lang.NoSuchMethodError: Sender..
http://bugs.sun.com/view_bug.do?bug_id=6920138
-Chris.
Jack Bates wrote:
Thanks again Michael, is there a URL for this bug? Can I check its
status?
On Tue, 2010-01-26 at 12:16 +, Michael McMahon wrote:
Jack,
6920138 is the reference for this bug.
Thanks,
Michael.
Jack Bates wrote:
Hi
many sockets as we
like during authentication, and then just store the last one that
connected as this internal socket? This seems like a way to "change
socket identities" like I suggested.
Thank you
Damjan
On Mon, Mar 1, 2010 at 4:29 PM, Christopher Hegarty - Sun Microsystems
Ireland wrote:
Hi
Hi All,
This patch fixes a problem where the socks proxy implementation does not
honor the timeout specified in Socket.connect(SocketAddress, timeout).
In fact, it uses the read timeout set with setSoTimeout since the socks
implementation opens a connection to the socks server to perform the
dering if we should
just proceed with it as is for now. Authentication is the reason that
this RFE never made it back yet and has been sitting for a few years now.
-Chris.
On 24/02/2010 17:28, Damjan Jovanovic wrote:
On Mon, Feb 22, 2010 at 5:02 PM, Christopher Hegarty - Sun
Microsystems I
Changeset: c96d6cb31723
Author:chegar
Date: 2010-02-23 17:08 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c96d6cb31723
6365587: Proxy-Connection header sent through tunnel
Reviewed-by: michaelm
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
Hi Michael,
I need a review for CR 6365587: "Proxy-Connection header sent through
tunnel".
Proxy-Connection header is being sent to the http server over an SSL
tunnel. The Proxy-Connection header is only of interest to the proxy.
You can see in our
sun.net.www.protocol.http.HttpURLConnectio
Changeset: e83d9c0d5e95
Author:chegar
Date: 2010-02-22 15:27 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e83d9c0d5e95
6912868: "java.net.useSystemProxies" behavior fails to check "use_same_proxy"
in GNOME
Reviewed-by: alanb, chegar
Contributed-by: damjan@gmail.com
!
Hi Damjan,
Actually, I did some work on this back in 2006 (!), but never finished
it. I brought the changes into a mercurial repository and created a webrev:
http://cr.openjdk.java.net/~chegar/6370908/webrev.00/webrev/
Basically, this change provides the basic functionality, without any
fr
Alan Bateman wrote:
[snip]
>
Looks okay to me. Sometime it might be good to re-write this in java
and just have a couple of simple native method to call the gconf_
functions.
Thanks Alan. I agree, this would be more elegant if rewritten in Java.
I'll proceed with this change and file a
Hi All,
This patch corrects Java's usage of Gnome's proxy setting, in particular
the previously ignored "use_same_proxy" setting as described on
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6912868 and
https://bugzilla.redhat.com/show_bug.cgi?id=536704.
I've added a manual test where th
Changeset: ec438f2b6886
Author:chegar
Date: 2010-02-10 13:23 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ec438f2b6886
6693244: Java Web Start app fails on 6u10 beta w/ AssertionError in
AuthenticationInfo.requestCompleted
Reviewed-by: michaelm
! src/share/classes/sun/net
Hi Michael,
This is a forward port to JDK7. The very same fix is already in 6u10,
5.0uXX and 1.4.2_XX.
There is the possibility that endAuthRequest can be invoked twice with
the same key. endAuthRequest in turn invokes requestCompleted, which
contains the assertion. If an authentication requ
Hi Alan, Michael,
While investigating another issue I noticed that there is quite a bit of
redundant static caching of methodIDs, fieldIDs, and global references
to class objects. Most of these are for InetAddress, Inet4Address,
Inet6Address and NetworkInterface.
These classes already provid
Changeset: 8df0ffac7f4d
Author:chegar
Date: 2010-01-27 16:11 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8df0ffac7f4d
6905552: libnet/nio portability issues
Reviewed-by: alanb
! src/share/native/java/net/net_util.c
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/so
On 27/01/2010 14:55, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi Alan, Michael,
Since we don't typically build on non-IPv6 systems, over a number of
years the net/nio code has not maintained clean non-IPv6 code. This
patch addresses that by excluding
Hi Alan, Michael,
Since we don't typically build on non-IPv6 systems, over a number of
years the net/nio code has not maintained clean non-IPv6 code. This
patch addresses that by excluding IPv6 specific code where AF_INET6 is
not defined.
6905552: libnet/nio portability issues
Webrev: http
Hi Mark,
I finally got around to this one. It will be fixed in the next JDK7
promotion, b83.
For reference,
Changeset:
http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e67bf9abc6a5
Review:
http://mail.openjdk.java.net/pipermail/net-dev/2010-January/001502.html
-Chris.
On 14/12/2009 16:27, M
Changeset: e67bf9abc6a5
Author:chegar
Date: 2010-01-25 15:41 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e67bf9abc6a5
6707289: InterfaceAddress.getNetworkPrefixLength() does not conform to Javadoc
Reviewed-by: michaelm
! src/windows/native/java/net/NetworkInterface_winXP.
Hi Micahel, Jessie,
6707289: InterfaceAddress.getNetworkPrefixLength() does not conform to
Javadoc
getAddrsFromAdapter
(src/windows/native/java/net/NetworkInterface_winXP.c) makes an
incorrect assumption that the list of IP_ADAPTER_PREFIX structures
pointed to by the FirstPrefix member has
Andrew John Hughes wrote:
2010/1/8 Christopher Hegarty - Sun Microsystems Ireland
:
On 08/01/2010 16:32, Andrew John Hughes wrote:
For OpenJDK6, I think it would be better to port over SCTP after the
b18 release which is currently undergoing final testing. So please
don't
Changeset: e0870a19b09e
Author:chegar
Date: 2010-01-18 14:56 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0870a19b09e
6917317: (sctp) Remove dependency on handleSocketError
Reviewed-by: alanb
! src/solaris/native/sun/nio/ch/SctpNet.c
! test/com/sun/nio/sctp/SctpChannel/Co
Problem Description:
handleSocketError is an exported nio function in JDK7, but not JDK6. The
sctp implementation calls it in the case of an error on the socket. You
will receive an error from the dynamic linker becuase this function is
not in libnio of JDK6, if running SCTP with Suns JDK6.
Changeset: 680d7d312a30
Author:chegar
Date: 2010-01-18 14:01 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/680d7d312a30
6916890: (sctp) SctpChannel.send may cause IAE if given a heap buffer with an
offset
Reviewed-by: alanb
! src/solaris/classes/sun/nio/ch/SctpChannelImpl.
Changeset: b019cdae32dd
Author:chegar
Date: 2010-01-15 16:31 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b019cdae32dd
6916922: (sctp) SO_RCVBUF & SO_SNDBUF returns twice the value set
Reviewed-by: alanb
! src/solaris/native/sun/nio/ch/SctpNet.c
! test/com/sun/nio/sctp/Sct
In the case where a heap buffer is supplied the implementation copies
the data into a temporary native buffer before going native. The
position and remaining data is incorrectly determined for this temporary
buffer when the position of the original buffer is not 0.
Also, remove incorrect asser
see discussion on sctp-dev:
http://mail.openjdk.java.net/pipermail/sctp-dev/2010-January/000151.html
Essentially, on Linux SO_SNDBUF/SO_RCVBUF aren't symmetric. This stems
from additional socket structures in the send and receive buffers.
Net_GetSockOpt handles this by dividing the retrieved
Changeset: fc5578368a0c
Author:chegar
Date: 2010-01-11 16:04 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fc5578368a0c
6915313: Reorganize implementation to make it more feasible to port to JDK6
Summary: This makes the SCTP implementation easier to run with Suns JDK6.
Revie
On 10/01/2010 16:27, Alan Bateman wrote:
If I understand correctly, you're trying to help the folks that want to
take this code and hack on it with jdk6 - is that right?
Yes, this is correct.
Have you
considered creating a page on the SCTP project with the recipe.
This is a great idea
On 08/01/2010 16:32, Andrew John Hughes wrote:
For OpenJDK6, I think it would be better to port over SCTP after the
b18 release which is currently undergoing final testing. So please
don't push anything to the OpenJDK6 repositories just yet :-)
Oh, maybe the bug description is a little
Hi,
We have received several requests about porting the SCTP API to JDK6.
This bug aims to amend the current implementation to minimize the amount
of changes required to port it to JDK6.
1) Remove JDK7 API dependences from the implementation
2) provide all native functionality within libsctp.
Hi Mark,
I've actually just reproduced this myself on one of our Vista boxes.
I've accepted the bug, 6707289, and will try to determine the root cause.
-Chris.
On 14/12/2009 16:27, Mark Thornton wrote:
On Vista, if you try to find the broadcast address and net prefix length
associated with a
? Possibly:
HttpContext createContext(String host, String path, HttpHandler handler)
Also, we need to think of the implications on HttpsServer.
Michael (cc'ed) is the author of this API. Maybe he has an opinion.
-Chris.
On 07/12/2009 11:23, Christopher Hegarty - Sun Microsystems Ireland wrote:
Th
Changeset: ae944611249f
Author:chegar
Date: 2009-12-10 15:52 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae944611249f
6909089: Memory leak occurs by lack of free for read buffer in
SocketInputStream#read()
Reviewed-by: alanb, jccollet
! src/windows/native/java/net/Socket
Alan Bateman wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
CR 6909089: Memory leak occurs by lack of free for read buffer in
SocketInputStream#read()
Webrev:
http://cr.openjdk.java.net/~chegar/6909089/webrev.0/webrev/
Bug description says it all.
-Chris.
Looks okay to me
CR 6909089: Memory leak occurs by lack of free for read buffer in
SocketInputStream#read()
Webrev:
http://cr.openjdk.java.net/~chegar/6909089/webrev.0/webrev/
Bug description says it all.
-Chris.
Jean-Christophe Collet wrote:
[snip]
What's happening here is that the ProxySelector() is not called to check
whether the URLConnection should use a proxy but whether the Socket
should use a SOCKS proxy.
Good catch Jessie, I missed that.
I was just about to run the test, no need to now.
-C
This is certainly interesting. Let me take a look and I'll get back to
you later.
-Chris.
On 04/12/2009 20:17, David M. Lloyd wrote:
I've crafted a simple patch which extends the API of the embedded HTTP
server to support virtual hosts. The patch is designed to add the new
functionality with
On 05/12/2009 00:01, Paulo Levi wrote:
-- Forwarded message --
From: Paulo Levi
Date: Fri, Dec 4, 2009 at 9:57 PM
Subject: Re: Bug in URLConnection?
To: Christopher Hegarty -Sun Microsystems Ireland <
christopher.hega...@sun.com>
The problem is that the user (or any
Paulo Levi wrote:
Besides sending a Proxy to the connection should mean that the
connection is going to use that proxy if any? Why ask the proxy selector
anything?
Sorry Paulo I'm not seeing the behavior you are describing.
When making a http request and with a custom proxy selector set I see
Hi Paulo,
I must admit that making a URLConnection request from within select
looks a little funny, but I don't think it should cause a problem. I've
run the test you posted and I don't see the default proxy selector being
invoke. I only see the user defined selector. Can you provide more
inf
This change looks fine.
-Chris.
Jean-Christophe Collet wrote:
This is a simple fix for a cookie parsing issue.
http://cr.openjdk.java.net/~jccollet/6901170/webrev.0/
Thanks,
The changes look fine.
-Chris.
On 23/10/2009 14:57, Alan Bateman wrote:
I need a reviewer for a small fix to sun.net.NetHooks. On Solaris, the
code incorrectly assumes that the sdp provider is always present. The
loadProvider method should return null if not present. The diffs are
attached.
Changeset: 93f8d9494e05
Author:chegar
Date: 2009-10-22 15:44 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93f8d9494e05
6894169: Move HttpLogFormatter into a separate package
Reviewed-by: alanb
! make/sun/net/FILES_java.gmk
- src/share/classes/sun/net/www/protocol/http/Http
CR 6894169: Move HttpLogFormatter into a separate package
Webrev:
http://cr.openjdk.java.net/~chegar/6894169/webrev.0/webrev/
Moving HttpLogFormatter out of sun.net.www.protocol.http and into
sun.net.www.protocol.http.logging will simplify the modularization
effort by making it easier to def
Changeset: 44fa9caa1727
Author:chegar
Date: 2009-10-21 15:41 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/44fa9caa1727
6893238: Move NTLM and SPNEGO implementations into separate packages
Reviewed-by: michaelm, alanb
! make/java/net/Makefile
! make/sun/net/FILES_java.gmk
!
On 21/10/2009 15:47, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
:
Yes, this would certainly be cleaner. I've updated the webrev. Please
take a look.
http://cr.openjdk.java.net/~chegar/6893238/webrev.1/webrev/
Note: The lack of the initial cause o
On 21/10/2009 15:05, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
CR 6893238: Move NTLM and SPNEGO implementations into separate packages
Webrev:
http://cr.openjdk.java.net/~chegar/6893238/webrev.0/webrev/
Following 688259, NTLM and SPNEGO authentication
CR 6893238: Move NTLM and SPNEGO implementations into separate packages
Webrev:
http://cr.openjdk.java.net/~chegar/6893238/webrev.0/webrev/
Following 688259, NTLM and SPNEGO authentication implementations are now
runtime dependencies. There is no reason that their implementations
should resi
Looks fine.
-Chris.
Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/6886436/webrev.03/
Thanks,
Michael.
Changeset: f864c15f6779
Author:chegar
Date: 2009-10-07 17:23 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f864c15f6779
6887364: SetOutgoingIf.java fails if run on multihomed machine without PIv6 on
all interfaces
Reviewed-by: alanb
! test/java/net/MulticastSocket/SetOutgo
Alan Bateman wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Hi Pavel, Michael,
6887364: SetOutgoingIf.java fails if run on multihomed machine without
PIv6 on all interfaces [more details below]
Webrev:
http://cr.openjdk.java.net/~chegar/6887364/webrev/
I just realized why
Hi Pavel, Michael,
6887364: SetOutgoingIf.java fails if run on multihomed machine without
PIv6 on all interfaces [more details below]
Webrev:
http://cr.openjdk.java.net/~chegar/6887364/webrev/
I just realized why this test was failing on one of our lab machines.
The reason is that the test
The actual changes look fine.
I have just a few comments/questions about the test:
1) copyright year should be updated to 2009
2) I don't think s1 needs to be a field. I think it should be
a local in run.
3) Indentation of run looks a little too far.
4) error should be volatile.
5) I would hav
Seems reasonable.
-Chris.
On 28/09/2009 10:45, Michael McMahon wrote:
Can I get the following test case change reviewed?
http://cr.openjdk.java.net/~michaelm/6886108/webrev.01/
The problem is a test case binding to a fixed port number
which fails randomly, if the port is in use. The test need
This change looks fine.
-Chris.
On 24/09/2009 10:01, Pavel Tisnovsky wrote:
Hi,
updated patch for regression test
java/net/MulticastSocket/SetOutgoingIf.java is exposed at
http://cr.openjdk.java.net/~ptisnovs/JTReg_SetOutgoinfIf_isUp/
This patch ensures, that this test uses only network de
your answer. I'll update the test and make the webrev.
FYI: in fact, the test java/net/MulticastSocket/Test.java fails too on
my machine, but I just not (yet) investigated the issue. It fails with
exception java.net.SocketException: Cannot assign requested address.
Pavel
Christopher He
1 - 100 of 183 matches
Mail list logo
