Would it make sense to test if it's resolved before constructing the new
InetSA?
This seems reasonable to me: someone could replace ProxySelector by calling ProxySelector.setDefault() method with the one returning resolved InetSA. Note, that as default ProxySelector always returns unresolved addresses then without this check we could save 1 extra check for default cases, but as this is a slow http - users will not notice the changes :-). Regards, Mikhail On 2/2/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I don't doubt the patch is correct and works - I just didn't grok why this was this way. :) I understand better now - that Proxy *could* actually be resolved, in which case things would have worked. Would it make sense to test if it's resolved before constructing the new InetSA? geir On Feb 2, 2007, at 12:20 PM, Mikhail Loenko wrote: > 2007/2/2, Mikhail Markov <[EMAIL PROTECTED]>: >> Here is the explanation: >> When creating java.net.Proxy object, createProxy() method in >> java.net.ProxySelectorImpl class uses >> InetSocketAddress.createUnresolved() >> method. In this case ((InetSocketAddress) proxy.address >> ()).getAddress() will >> return null, while getHostName() and getPort() method will return >> correct >> results. >> And Socket.connect(SocketAddress, int) method uses getAddress() >> method. >> Mikhail's fix create normal resolved InetSocketAddress which >> getAddress() >> returns normal non-null InetAddress. >> >> I've checked the behaviour of Socket.connect(SocketAddress, int) >> on RI - it >> also throws java.net.UnknownHostException in case of unresolved >> SocketAddress. >> And finally i've checked that Proxy objects created in RI are also >> contains >> unresolved addresses. > > I've made exactly these two tests on RI when was thinking about the > patch... > > you know this saying ;) > > Thanks, > Mikhail L > > > >> >> So, Mikhail patches the correct piece of code and his patch is >> correct :-). >> >> Regards, >> Mikhail >> >> >> >> >> >> On 2/2/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> > >> > This patch bugs me because it seems like a bit of a hack around a >> > problem elsewhere, although it could simply be because I don't know >> > what I'm talking about :) >> > >> > Anyway, I guess my problem boils down to this : >> > >> > The code now is : >> > >> > socket.connect(proxy.address(), .... ); >> > >> > and the new code is (in shorthand ) : >> > >> > socket.connect( new InetSA(proxy.getHostName(), proxy.getPort >> > ()), ....); >> > >> > why doesn't proxy.address() return a resolved SocketAddress - >> IOW, do >> > the same thing as this patch is doing? >> > >> > geir >> > >> > >> > On Feb 2, 2007, at 4:58 AM, Mikhail Loenko wrote: >> > >> > > hi >> > > >> > > I'm trying to build Harmony classlib on Harmony JDK (linux/ia32) >> > > >> > > "ant" and "ant clean" work just fine :) >> > > >> > > "ant -v fetch-depends" prints the following: >> > > >> > > java.net.ConnectException: people.apache.org/140.211.11.9:80 - >> > > Connection timed >> > > >> > > please review my patch at >> > > http://issues.apache.org/jira/browse/HARMONY-3113 >> > > >> > > Thanks, >> > > Mikhail >> > >> > >>
