Hi Roman,
This method was added as part of the changes for 4868820: "IPv6 support
for Windows XP and 2003 server", back in 1.5. But I cannot see anywhere
that it is called, or as you said even implemented, even when it was
originally added. I suspect that it was left over from some redesign
w
Martin Buchholz wrote:
On Mon, Feb 2, 2009 at 05:42, Christopher Hegarty - Sun Microsystems
Ireland wrote:
+static int isAsciiSpace(char c) {
+ return (((c) == '\t') || ((c) == '\r') || ((c) == '\b') ||
+ ((c) == '\n') || ((c) == ' &
Some initial (picky) comments:
1) "Thread Safety
Instances of UrlEncodedQueryString are not not synchronized."
Typo: "not not".
I would expand this a little. Maybe taking wording similar to
java.util.HashMap:
"Note that this implementation is not synchronized. If multiple
Hi Roman,
The bug I filed against this issue is 6615656. It has not reached our
external bug interface yet, but should do so in the next few days. When
it does it will be reachable at:
http://bugs.sun.com/view_bug.do?bug_id=6615656
On another note, thanks you for the contribution. I have no
Forwarding this mail to the core libs mailing list as they are most
probably in a better position to answer it as they own the sun.rmi package.
-Chris.
Original Message
Subject: Strange problem w/ RMI HTTP to CGI socket factory
Date: Thu, 11 Oct 2007 15:57:48 -0400
From: Sarel
Hi Roman,
I have reviewed your proposed changes and they look fine. I agree that
both java.net.NetworkInterface.getSubnet0 and
java.net.NetworkInterface.getBroadcast0 are unimplemented and should
also be removed.
We should be able to remove these NetworkInterface methods under CR
6615656 als
Yes, I see that you are already signed up.
I will proceed to review your fix and will be in contact shortly.
Regards,
-Chris.
I am not familiar with the Windows DNS service, but I cannot image how
the FQDN can be retrieved without a reverse entry in the DNS server. I
suspect that you will need to populate "Reverse Lookup Zones" with the
names of any machines you wish to be able to get the FQDN for.
-Chris.
Max (Weij
The change looks good. I approve this change.
-Chris
Jean-Christophe Collet wrote:
Here is my proposed fix for CR 6660405.
The issue is that after a redirect, and if there is a cache hit (i.e.
the URL is found in the cache) HttpURLConnection will return the wrong
InputStream. Details are in t
Yes, this change is fine.
-Chris.
Jean-Christophe Collet wrote:
This is a straightforward fix in mailtoURLConnection to remove a left
over debug statement in the connect() method.
Also took the opportunity to remove unneeded imports and add appropriate
@Override tags.
No regression test as th
CR 6667108: "typo in javadoc for java.net.Socket.getRemoteSocketAddress()"
Trivial cleanup of a typo in getRemoteSocketAddress specification.
diff -r fa6948bdc4b0 src/share/classes/java/net/Socket.java
--- a/src/share/classes/java/net/Socket.javaThu Mar 06 10:35:28 2008
-0800
+++ b/src/sha
Thanks Brad, this is great.
-Chris.
Brad Wetmore wrote:
Hi net-dev'ers,
This is Brad Wetmore, your friendly neighborhood JSN gatekeeper. For
some reason, pushes to the various JSN gates were initially configured
to send notifications only to the security group's aliases. That
problem has
Another trivial documentation change.
CR 6591358:
"documentation error in URLConnection.setRequestProperty("accept", ...)"
-Chris.
--- old/src/share/classes/java/net/URLConnection.java Fri Mar 7 11:19:24 2008
+++ new/src/share/classes/java/net/URLConnection.java Fri Mar 7 11:19:24 2008
@@
This change looks good.
-Chris.
Jean-Christophe Collet wrote:
Here are my proposed changes to fix 6644726
It does fix all 7 issues listed in the CR (see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6644726 for details)
and adds a proper regression test.
The short list is:
- support f
Hi,
I need to get a code review for,
CR 6687282 : "URLConnection for HTTPS connection through Proxy w/
Digest Authentication gives 400 Bad Request".
Digest authentication uses the request-URI as part of its algorithm when
generating the response hash. The request-URI is usually the abs_path
This change looks good.
-Chris.
Jean-Christophe Collet wrote:
I need a code review for the simple fix to 6558853.
It's a simple case of a flag not set in the native code when creating a
Inet6Address.
Patch attached below.
Thanks
Since this is a question about java.net.URI I am moving this question to
the OpenJDK Net Dev alias.
I will try to answer it there.
-Chris.
Michal Vyskocil wrote:
Hi all,
I'm working on adopting of jpackage project to openSUSE and got a problem with
build of maven. The jpackage's folks have
rgument.
You can look at the java.net.URI class description to give you a better
understanding of how this encoding works.
-Chris.
Christopher Hegarty - Sun Microsystems Ireland wrote:
Since this is a question about java.net.URI I am moving this question to
the OpenJDK Net Dev alias.
I will t
Thanks for the update Michal.
It is nice to know that even though this was not our bug we were able to
help diagnose the problem.
-Chris.
Michal Vyskocil wrote:
On Tuesday 29 April 2008 18:21:43 Christopher Hegarty - Sun Microsystems
Ireland wrote:
The square bracket characters ('[
I think that this thread should be moved to the net-dev alias.
I know that Michael is certainly a member of net-dev and is currently
the owner of the HTTP server.
-Chris.
David M. Lloyd wrote:
On 05/27/2008 02:15 PM, Alan Bateman wrote:
Juha Lindfors wrote:
On Tue, May 27, 2008 at 7:03 P
Hi,
I just sent a mail to the nio-discuss [1] mailing list requesting
feedback on a proposed Java API for SCTP. If you are interested in this
topic please read this mail which provides a some details and a link to
the API. Feedback is really welcome.
-Chris.
[1]
http://mail.openjdk.java.ne
On 08/26/08 14:41, David M. Lloyd wrote:
On 08/20/2008 04:37 AM, Alan Bateman wrote:
Florian Weimer wrote:
:
I've been wondering for a while if it is possible (with reasonable
additional effort) to add new socket and socket address classes without
patching the JDK sources.
No, it's not. :-)
Joseph D. Darcy wrote:
Yes, I've already asked Chris to fix this in OpenJDK 6 too.
I pushed these changes into the OpenJDK 6 workspace, so it will be in
the next build/push.
-Chris.
Regards,
-Joe
In accordance with the OpenJDK guidelines for projects [1], I hereby
propose an OpenJDK Project "SCTP".
This Project will be used for the development of an API for Stream
Control Transport Protocol (SCTP) and corresponding OpenJDK prototype.
I propose this project be sponsored by the Networki
Vote: yes
Michael McMahon wrote:
Greetings, voting members of the Networking Group!
Question: Should the Networking Group sponsor the "SCTP" Project[1]?
Please cast your vote by replying, publicly, to this message with either
Vote: yes
or
Vote: no
as the first line of the message body.
Yo
Hi Alan,
Yes, I will assign 6799040 to myself and work with Christos to finalize
the networking changes.
Thanks,
-Chris.
Alan Bateman wrote:
Christos mailed core-libs-dev yesterday with a few portability
issues.Anyone have cycles to look at the Inet4AddressImpl.c changes?
I've created 67990
**
* Macros and constants
*/
-Chris.
[1]
http://hg.openjdk.java.net/jdk7/tl/jdk/annotate/f9cf49b7b248/src/solaris/native/java/net/Inet6AddressImpl.c
On 01/30/09 10:36, Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi Alan,
Yes, I will assign 6799040 t
the final changes:
http://cr.openjdk.java.net/~chegar/6799040
Thanks,
-Chris.
On 02/02/09 22:13, Christopher Hegarty - Sun Microsystems wrote:
Martin Buchholz wrote:
On Mon, Feb 2, 2009 at 05:42, Christopher Hegarty - Sun Microsystems
Ireland wrote:
+static int isAsciiSpace(char c) {
+ return
I need to get a code review for
6800805: java.net.NetworkInterface.getNetworkInterfaces() does not
list IPv6 network interfaces correctly.
http://cr.openjdk.java.net/~chegar/6800805/webrev.00/
There is a change in behaviour between JDK5 and JDK6 in how virtual
interfaces addresses are repor
Hi Michael, Jessie,
Please take a few moments to review this trivial change:
http://cr.openjdk.java.net/~chegar/6775145/webrev.00/webrev/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6775145
6775145: ClassLoaderUtil.releaseLoader calls System.out.println
("classLoader
Hi Michael, Jessie,
Please take a few moments to review this trivial change:
6737323: Typo in javadoc for SocketPermission
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6737323
http://cr.openjdk.java.net/~chegar/6737323/webrev.00/webrev/
Very trivial changes - remove redundant lin
Hi Max,
I only looked at the networking part of the changes. They look fine, I
just have a few questions/comments:
1) sun.net.www.protocol.http.HttpURLConnection
Can you use the same HttpCallerInfo instance for proxy authentication
at line 1108? This instance has been created using the s
s
Mx
On Apr 14, 2009, at 8:55 PM, Max (Weijun) Wang wrote:
On Apr 14, 2009, at 5:59 PM, Christopher Hegarty - Sun Microsystems
Ireland wrote:
Hi Max,
I only looked at the networking part of the changes. They look fine,
I just have a few questions/comments:
1) sun.net.www.protocol.http.Ht
right before the service principal name is
created.
I also add a test, putting two Kerberos KDC, one HTTP server, one proxy
server in a single regression test is fun!
Thanks
Mx
On Apr 14, 2009, at 8:55 PM, Max (Weijun) Wang wrote:
On Apr 14, 2009, at 5:59 PM, Christopher Hegarty - Sun Microsys
Hi Jessie, Michael, Alan,
I would like to try and get this simple change into b59 through the
build integration slot, and therefore make M3. The change is simply to
the docs Makefile so that the SCTP API docs are generated.
CR 6837982:
SCTP API docs not being generated.
Webrev:
http://cr
, jgss and smartcardio javadoc files do not contain Copyrights
Thanks
Max
On May 6, 2009, at 11:28 PM, Christopher Hegarty - Sun Microsystems
Ireland wrote:
Hi Jessie, Michael, Alan,
I would like to try and get this simple change into b59 through the
build integration slot, and therefore ma
I filed the follow bug for this:
6838450: Sun specific APIs should have consistent copyright footer
-Chris.
On 05/07/09 12:10, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
Great, thanks Max,
I've added the footer and updated the webrev
Hi Jessie, Michael, Alan,
6807602: Increase MAX_BUFFER_LEN and MAX_HEAP_BUFFER_LEN on 64-bit
Solaris and Linux
Webrev:
http://cr.openjdk.java.net/~chegar/6807602/webrev.00/webrev/
This is a forward port of a change that went into 6u14. It does exactly
what it says on the tin!
Thanks,
-Ch
Hi Michael, Jessie,
I need a code review for some SCTP changes that were found during testing.
CR 6855335:
Several changes in the SCTP implementation.
Webrev:
http://cr.openjdk.java.net/~chegar/6855335/webrev.00/webrev/
1) SctpMultiChannel.branch returns null.
branch was not implemented
On 29/06/2009 11:32, Michael McMahon wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi Michael, Jessie,
I need a code review for some SCTP changes that were found during
testing.
CR 6855335:
Several changes in the SCTP implementation.
Webrev:
http://cr.openjdk.java.net
Hi,
Newly connected and accepted SctpChannels eagerly receive the COMM_UP
notification so that an Association can be created with the appropriate
in/out streams. This of course removes the notification from the native
stack and caches it at the java level so that it can be received later
by t
Hi Martin,
Thanks for reporting this. We actually already know about it, but
somehow haven't gotten around to fixing it in JDK7 yet. I'll put it on
the list for M6.
6693244: Java Web Start app fails on 6u10 beta w/ AssertionError in
AuthenticationInfo.requestCompleted
Thanks,
-Chris.
On 2
Looks good.
-Chris.
On 15/09/2009 15:36, Jean-Christophe Collet wrote:
Here are the changes for 6737819.
This allows for the previously hard-coded, always in, values for
http.nonProxyHosts and ftp.nonProxyHosts to be overridden when necessary.
I.E. before it was never possible to reach localho
Hi Jessie, Michael, Alan,
6882594: Remove static dependency on NTLM authentication
Webrev:
http://cr.openjdk.java.net/~chegar/6882594/webrev.0
The HTTP client implementation
(sun.net.www.protocol.http.HttpURLConnection) loads the NTLM
Authentication classes even if no authentication is used
6882609: Move default InMemoryCookieStore to java.net
Webrev:
http://cr.openjdk.java.net/~chegar/6882609/webrev.0/webrev/
The default cookie store implementation (InMemoryCookieStore) currently
resides in sun.net.www.protocol.http. There is no reason for it to live
there, and it actually put
6882654: Remove dependency on java.util.concurrent from KeepAlive
implementaion
Webrev:
http://cr.openjdk.java.net/~chegar/6882654/webrev.0/webrev/
The HTTP keep alive implementation has unnecessary dependencies on
java.util.concurrent classes.
KeepAliveCache subclasses ConcurrentHashMap
Hegarty - Sun Microsystems Ireland wrote:
Hi Jessie, Michael, Alan,
6882594: Remove static dependency on NTLM authentication
Webrev:
http://cr.openjdk.java.net/~chegar/6882594/webrev.0
The HTTP client implementation
(sun.net.www.protocol.http.HttpURLConnection) loads the NTLM
Authentication
be found at:
http://cr.openjdk.java.net/~chegar/6882594/webrev.1/webrev/
Thanks,
-Chris.
Thanks
Max
On Sep 17, 2009, at 6:55 PM, Christopher Hegarty -Sun Microsystems
Ireland wrote:
I removed the use of char (schemeId) completed and replaced it the the
new AuthScheme enum. This makes t
On 17/09/2009 21:18, Alan Bateman wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Max (Weijun) Wang wrote:
HttpURLConnection.java:
I think "if (authScheme.equals(BASIC))" can be written as
"authScheme == BASIC", and possibly you can use switch/case in
sev
6882384: Update http protocol handler to use PlatformLogger
Webrev:
http://cr.openjdk.java.net/~chegar/6882384/webrev.0/webrev/
Change http logging to use the PlatformLogger. We can simply remove the
reflective calls to the logging API from HttpCapture as the
PlatformLogger will take care o
On 22/09/2009 12:58, Alan Bateman wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
6882384: Update http protocol handler to use PlatformLogger
Webrev:
http://cr.openjdk.java.net/~chegar/6882384/webrev.0/webrev/
Change http logging to use the PlatformLogger. We can simply remove
[cc'ing net-dev]
Alan Bateman wrote:
Pavel Tisnovsky wrote:
Hi,
two-lines patch for regression test
java/net/MulticastSocket/SetOutgoingIf.java is exposed at
http://cr.openjdk.java.net/~ptisnovs/JTReg_SetOutgoinIf/
The test machine (where this test fails) has six network interfaces,
but o
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
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
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
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
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
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
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.
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
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
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
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
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.
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,
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
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
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
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
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
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.
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
? 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
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
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.
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
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
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
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
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.
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
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
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
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
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,
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
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 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
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 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
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
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
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
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
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
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..
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,
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
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,
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
1 - 100 of 127 matches
Mail list logo
