I was thinking about this, and it's actually a bug in java.net.URL: since the advent of HTTP 1.1, http://foo.bar/index.html will very often be different from http://zutano.mengano/index.html even if both names point to the same IP.

So I searched the Java bug parade and found bug#4434494: http://developer.java.sun.com/developer/bugParade/bugs/4434494.html. In the comments to that I found this:


[...] to address URI parsing in general, we introduced a new class called URI in Merlin (jdk1.4). People are encouraged to use URI for parsing and URI comparison, and leave URL class for accessing the URI itself, getting at the protocol handler, interacting with the protocol etc. So, at present, we don't plan on changing the URL.equals/hashCode behavior [...]


--
Salut,

Jordi.

En/na Jordi Salvat i Alabart ha escrit:


En/na [EMAIL PROTECTED] ha escrit:


+ // TODO: maybe change the API to return URL Strings instead of java.net.URLs?



Since the HTTPSampler would need to re-create the URLs in order to use them, perhaps we could use URL.toString() as the hash key,
and store the URL as the value? Would require more storage, but no need to recreate the URLs.



GREAT idea! The need to recreate the URLs was actually the reason for the question mark at the end of the phrase.


Might be fun to create a Collection to handle this automatically - or there may already be something suitable in Commons-Collections
(which JMeter already uses - albeit by ListenerNotifier only!).



Fun yes. But probably an overkill.




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to