You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2012/08/06 14:38:38 UTC
PreferredClassProvider: URL and URI
It turns out the recent failures on Solaris x64 hudson are due to an
illegal character in the URI host name string:
Testcase:
testCrossPlatformNormalise(org.apache.river.impl.net.UriStringTest):
Caused an ERROR
Illegal character in hostname at index 13:
http://hudson_solaris:9081/nonactivatablegroup-dl.jar
java.net.URISyntaxException: Illegal character in hostname at index 13:
http://hudson_solaris:9081/nonactivatablegroup-dl.jar
The hostname is incorrectly parsed only as an authority component when
passed to the constructor URI(String str), leading to the errors seen in
failing hudson tests.
So the good news is, it isn't a problem with Solaris x64.
But it does raise some important questions.
But first some background...
The summary of semantic changes:
* Previous releases of Jini & River PreferredClassProvider have
relied upon URL and the calling threads context ClassLoader
(called the parent loader) to determine the correct
PreferredClassLoader. Basically URL resolves to an IP address, so
the ClassLoader was determined by the IP address of the codebase
and the calling threads context ClassLoader.
* We could use URI and the calling Threads context ClassLoader
instead. This means that the PreferredClassLoader would be
determined by the normalised form of the URI and the context
ClassLoader.
The nitty gritty:
* Relying on the IP address probably made sense in the 90's, today
there are issues with virtual hosts, dynamic ip addresses and
maintaining a fixed IP address over time and failover codebase
replication so that the codebase always appears as the same IP
address to clients. You might also imagine that if Jini / River
hits the internet, that NAT and routing would cause some big
problems. This doesn't mean we couldn't continue to use URL and
provide a URL Handler for some new protocol that solves these issues.
* Changing to URI brings some big benefits, but it comes at a
price. The benefits are an added layer of indirection, a
documented standard that can be used to predict ClassLoader
selection reliably, regardless of protocol. Cheaper code base
replication, backup and regional redirection and hosting of
codebases. (Obviously signing jar files will be an important step
to prevent unwanted codebase mixing -eg a remote codebase attack
with DNS posioning). Dynamic IP addresses, virtual hosts and fail
over hosting will work too. What's the price you may ask? For
proper comparison, URI's must have a strictly restricted character
set and be normalised EG: legal but escaped characters must be
unescaped, the scheme must be in lower case, the host must also be
in lower case, the path is case sensitive (file URL paths on
Windows must be converted to upper case). Only after
normalisation is complete can we accurately call hashCode() and
equals() on URI instances, since this eliminates false negatives.
* Avoid using the underscore (_) character in machine names.
Internet standards dictate that domain names conform to the
host name requirements described in Internet Official Protocol
Standards RFC 952 and RFC 1123. Domain names must contain only
letters (upper or lower case) and digits. Domain names can
also contain dash characters ( - ) as long as the dashes are
not on the ends of the name. Underscore characters ( _ ) are
not supported in the host name.
* The huge benefit is now we can perform URI string based
comparison, without relying on a URL Handlers for identity, so
future URL Handlers will also have the same expected behaviour and
must conform to standards. This will also have huge performance
benefits, no longer will class resolution block on DNS calls, nor
will equals and hashCode comparison rely on DNS resolution.
Currently non conforming URL's can be loaded, such as
"http://hudson_solaris:9081/nonactivatablegroup-dl.jar", these will no
longer be supportable with URI.
What do you say? Do I revert to tried and tested URL (the devil we
know) or do I report a bug against the use of an underscore in the
hudson_solaris hostname and continue refining the use of URI?
Regards,
Peter.
Re: PreferredClassProvider: URL and URI
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Dan.
Cheers,
Peter.
On 8/08/2012 6:09 PM, Dan Creswell wrote:
> Yeah, sorry very busy with work and other bits and pieces but I agree with
> Chris, file the bug cos the RFCs say you're right.
>
> On 8 August 2012 08:32, Peter Firmstone<ji...@zeus.net.au> wrote:
>
>> Thanks Chris,
>>
>> The dev list has been quiet, but we still appear to be making good
>> progress, my effots look like complementing Greg's work and the work
>> Gregg's planning, so the next release will hopefully fix a number of long
>> standing issues. With fundamental semantic changes to
>> PrefferedClassProvider, it might be worth incrementing River to version
>> 3.0. The change to URI from URL may cause problems in some deployment
>> environments, it isn't 100% backward compatible, although on a positive
>> note, no code needs to be recompiled.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>>
>> On 6/08/2012 11:19 PM, Christopher Dolan wrote:
>>
>>> I say file a bug against the underscore. I've fought this battle before
>>> and lost...
>>> http://domainkeys.sourceforge.**net/underscore.html<http://domainkeys.sourceforge.net/underscore.html>
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Peter Firmstone [mailto:jini@zeus.net.au]
>>> Sent: Monday, August 06, 2012 7:39 AM
>>> To:dev@river.apache.org
>>> Subject: PreferredClassProvider: URL and URI
>>>
>>> It turns out the recent failures on Solaris x64 hudson are due to an
>>> illegal character in the URI host name string:
>>>
>>> Testcase:
>>> testCrossPlatformNormalise(**org.apache.river.impl.net.**UriStringTest):
>>> Caused an ERROR
>>> Illegal character in hostname at index 13:
>>> http://hudson_solaris:9081/**nonactivatablegroup-dl.jar<http://hudson_solaris:9081/nonactivatablegroup-dl.jar>
>>> java.net.URISyntaxException: Illegal character in hostname at index 13:
>>> http://hudson_solaris:9081/**nonactivatablegroup-dl.jar<http://hudson_solaris:9081/nonactivatablegroup-dl.jar>
>>>
>>> The hostname is incorrectly parsed only as an authority component when
>>> passed to the constructor URI(String str), leading to the errors seen in
>>> failing hudson tests.
>>>
>>> So the good news is, it isn't a problem with Solaris x64.
>>>
>>> But it does raise some important questions.
>>>
>>> But first some background...
>>>
>>> The summary of semantic changes:
>>>
>>> * Previous releases of Jini& River PreferredClassProvider have
>>> relied upon URL and the calling threads context ClassLoader
>>> (called the parent loader) to determine the correct
>>> PreferredClassLoader. Basically URL resolves to an IP address, so
>>> the ClassLoader was determined by the IP address of the codebase
>>> and the calling threads context ClassLoader.
>>> * We could use URI and the calling Threads context ClassLoader
>>> instead. This means that the PreferredClassLoader would be
>>> determined by the normalised form of the URI and the context
>>> ClassLoader.
>>>
>>> The nitty gritty:
>>>
>>> * Relying on the IP address probably made sense in the 90's, today
>>> there are issues with virtual hosts, dynamic ip addresses and
>>> maintaining a fixed IP address over time and failover codebase
>>> replication so that the codebase always appears as the same IP
>>> address to clients. You might also imagine that if Jini / River
>>> hits the internet, that NAT and routing would cause some big
>>> problems. This doesn't mean we couldn't continue to use URL and
>>> provide a URL Handler for some new protocol that solves these
>>> issues.
>>> * Changing to URI brings some big benefits, but it comes at a
>>> price. The benefits are an added layer of indirection, a
>>> documented standard that can be used to predict ClassLoader
>>> selection reliably, regardless of protocol. Cheaper code base
>>> replication, backup and regional redirection and hosting of
>>> codebases. (Obviously signing jar files will be an important step
>>> to prevent unwanted codebase mixing -eg a remote codebase attack
>>> with DNS posioning). Dynamic IP addresses, virtual hosts and fail
>>> over hosting will work too. What's the price you may ask? For
>>> proper comparison, URI's must have a strictly restricted character
>>> set and be normalised EG: legal but escaped characters must be
>>> unescaped, the scheme must be in lower case, the host must also be
>>> in lower case, the path is case sensitive (file URL paths on
>>> Windows must be converted to upper case). Only after
>>> normalisation is complete can we accurately call hashCode() and
>>> equals() on URI instances, since this eliminates false negatives.
>>>
>>> * Avoid using the underscore (_) character in machine names.
>>> Internet standards dictate that domain names conform to the
>>> host name requirements described in Internet Official Protocol
>>> Standards RFC 952 and RFC 1123. Domain names must contain only
>>> letters (upper or lower case) and digits. Domain names can
>>> also contain dash characters ( - ) as long as the dashes are
>>> not on the ends of the name. Underscore characters ( _ ) are
>>> not supported in the host name.
>>>
>>> * The huge benefit is now we can perform URI string based
>>> comparison, without relying on a URL Handlers for identity, so
>>> future URL Handlers will also have the same expected behaviour and
>>> must conform to standards. This will also have huge performance
>>> benefits, no longer will class resolution block on DNS calls, nor
>>> will equals and hashCode comparison rely on DNS resolution.
>>>
>>> Currently non conforming URL's can be loaded, such as
>>> "http://hudson_solaris:9081/**nonactivatablegroup-dl.jar<http://hudson_solaris:9081/nonactivatablegroup-dl.jar>",
>>> these will no
>>> longer be supportable with URI.
>>>
>>> What do you say? Do I revert to tried and tested URL (the devil we
>>> know) or do I report a bug against the use of an underscore in the
>>> hudson_solaris hostname and continue refining the use of URI?
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>>
>>>
>>>
>>>
>>>
Re: PreferredClassProvider: URL and URI
Posted by Dan Creswell <da...@gmail.com>.
Yeah, sorry very busy with work and other bits and pieces but I agree with
Chris, file the bug cos the RFCs say you're right.
On 8 August 2012 08:32, Peter Firmstone <ji...@zeus.net.au> wrote:
> Thanks Chris,
>
> The dev list has been quiet, but we still appear to be making good
> progress, my effots look like complementing Greg's work and the work
> Gregg's planning, so the next release will hopefully fix a number of long
> standing issues. With fundamental semantic changes to
> PrefferedClassProvider, it might be worth incrementing River to version
> 3.0. The change to URI from URL may cause problems in some deployment
> environments, it isn't 100% backward compatible, although on a positive
> note, no code needs to be recompiled.
>
> Cheers,
>
> Peter.
>
>
>
> On 6/08/2012 11:19 PM, Christopher Dolan wrote:
>
>> I say file a bug against the underscore. I've fought this battle before
>> and lost...
>> http://domainkeys.sourceforge.**net/underscore.html<http://domainkeys.sourceforge.net/underscore.html>
>> Chris
>>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au]
>> Sent: Monday, August 06, 2012 7:39 AM
>> To:dev@river.apache.org
>> Subject: PreferredClassProvider: URL and URI
>>
>> It turns out the recent failures on Solaris x64 hudson are due to an
>> illegal character in the URI host name string:
>>
>> Testcase:
>> testCrossPlatformNormalise(**org.apache.river.impl.net.**UriStringTest):
>> Caused an ERROR
>> Illegal character in hostname at index 13:
>> http://hudson_solaris:9081/**nonactivatablegroup-dl.jar<http://hudson_solaris:9081/nonactivatablegroup-dl.jar>
>> java.net.URISyntaxException: Illegal character in hostname at index 13:
>> http://hudson_solaris:9081/**nonactivatablegroup-dl.jar<http://hudson_solaris:9081/nonactivatablegroup-dl.jar>
>>
>> The hostname is incorrectly parsed only as an authority component when
>> passed to the constructor URI(String str), leading to the errors seen in
>> failing hudson tests.
>>
>> So the good news is, it isn't a problem with Solaris x64.
>>
>> But it does raise some important questions.
>>
>> But first some background...
>>
>> The summary of semantic changes:
>>
>> * Previous releases of Jini& River PreferredClassProvider have
>> relied upon URL and the calling threads context ClassLoader
>> (called the parent loader) to determine the correct
>> PreferredClassLoader. Basically URL resolves to an IP address, so
>> the ClassLoader was determined by the IP address of the codebase
>> and the calling threads context ClassLoader.
>> * We could use URI and the calling Threads context ClassLoader
>> instead. This means that the PreferredClassLoader would be
>> determined by the normalised form of the URI and the context
>> ClassLoader.
>>
>> The nitty gritty:
>>
>> * Relying on the IP address probably made sense in the 90's, today
>> there are issues with virtual hosts, dynamic ip addresses and
>> maintaining a fixed IP address over time and failover codebase
>> replication so that the codebase always appears as the same IP
>> address to clients. You might also imagine that if Jini / River
>> hits the internet, that NAT and routing would cause some big
>> problems. This doesn't mean we couldn't continue to use URL and
>> provide a URL Handler for some new protocol that solves these
>> issues.
>> * Changing to URI brings some big benefits, but it comes at a
>> price. The benefits are an added layer of indirection, a
>> documented standard that can be used to predict ClassLoader
>> selection reliably, regardless of protocol. Cheaper code base
>> replication, backup and regional redirection and hosting of
>> codebases. (Obviously signing jar files will be an important step
>> to prevent unwanted codebase mixing -eg a remote codebase attack
>> with DNS posioning). Dynamic IP addresses, virtual hosts and fail
>> over hosting will work too. What's the price you may ask? For
>> proper comparison, URI's must have a strictly restricted character
>> set and be normalised EG: legal but escaped characters must be
>> unescaped, the scheme must be in lower case, the host must also be
>> in lower case, the path is case sensitive (file URL paths on
>> Windows must be converted to upper case). Only after
>> normalisation is complete can we accurately call hashCode() and
>> equals() on URI instances, since this eliminates false negatives.
>>
>> * Avoid using the underscore (_) character in machine names.
>> Internet standards dictate that domain names conform to the
>> host name requirements described in Internet Official Protocol
>> Standards RFC 952 and RFC 1123. Domain names must contain only
>> letters (upper or lower case) and digits. Domain names can
>> also contain dash characters ( - ) as long as the dashes are
>> not on the ends of the name. Underscore characters ( _ ) are
>> not supported in the host name.
>>
>> * The huge benefit is now we can perform URI string based
>> comparison, without relying on a URL Handlers for identity, so
>> future URL Handlers will also have the same expected behaviour and
>> must conform to standards. This will also have huge performance
>> benefits, no longer will class resolution block on DNS calls, nor
>> will equals and hashCode comparison rely on DNS resolution.
>>
>> Currently non conforming URL's can be loaded, such as
>> "http://hudson_solaris:9081/**nonactivatablegroup-dl.jar<http://hudson_solaris:9081/nonactivatablegroup-dl.jar>",
>> these will no
>> longer be supportable with URI.
>>
>> What do you say? Do I revert to tried and tested URL (the devil we
>> know) or do I report a bug against the use of an underscore in the
>> hudson_solaris hostname and continue refining the use of URI?
>>
>> Regards,
>>
>> Peter.
>>
>>
>>
>>
>>
>>
>
Re: PreferredClassProvider: URL and URI
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Chris,
The dev list has been quiet, but we still appear to be making good
progress, my effots look like complementing Greg's work and the work
Gregg's planning, so the next release will hopefully fix a number of
long standing issues. With fundamental semantic changes to
PrefferedClassProvider, it might be worth incrementing River to version
3.0. The change to URI from URL may cause problems in some deployment
environments, it isn't 100% backward compatible, although on a positive
note, no code needs to be recompiled.
Cheers,
Peter.
On 6/08/2012 11:19 PM, Christopher Dolan wrote:
> I say file a bug against the underscore. I've fought this battle before and lost...
> http://domainkeys.sourceforge.net/underscore.html
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Monday, August 06, 2012 7:39 AM
> To:dev@river.apache.org
> Subject: PreferredClassProvider: URL and URI
>
> It turns out the recent failures on Solaris x64 hudson are due to an
> illegal character in the URI host name string:
>
> Testcase:
> testCrossPlatformNormalise(org.apache.river.impl.net.UriStringTest):
> Caused an ERROR
> Illegal character in hostname at index 13:
> http://hudson_solaris:9081/nonactivatablegroup-dl.jar
> java.net.URISyntaxException: Illegal character in hostname at index 13:
> http://hudson_solaris:9081/nonactivatablegroup-dl.jar
>
> The hostname is incorrectly parsed only as an authority component when
> passed to the constructor URI(String str), leading to the errors seen in
> failing hudson tests.
>
> So the good news is, it isn't a problem with Solaris x64.
>
> But it does raise some important questions.
>
> But first some background...
>
> The summary of semantic changes:
>
> * Previous releases of Jini& River PreferredClassProvider have
> relied upon URL and the calling threads context ClassLoader
> (called the parent loader) to determine the correct
> PreferredClassLoader. Basically URL resolves to an IP address, so
> the ClassLoader was determined by the IP address of the codebase
> and the calling threads context ClassLoader.
> * We could use URI and the calling Threads context ClassLoader
> instead. This means that the PreferredClassLoader would be
> determined by the normalised form of the URI and the context
> ClassLoader.
>
> The nitty gritty:
>
> * Relying on the IP address probably made sense in the 90's, today
> there are issues with virtual hosts, dynamic ip addresses and
> maintaining a fixed IP address over time and failover codebase
> replication so that the codebase always appears as the same IP
> address to clients. You might also imagine that if Jini / River
> hits the internet, that NAT and routing would cause some big
> problems. This doesn't mean we couldn't continue to use URL and
> provide a URL Handler for some new protocol that solves these issues.
> * Changing to URI brings some big benefits, but it comes at a
> price. The benefits are an added layer of indirection, a
> documented standard that can be used to predict ClassLoader
> selection reliably, regardless of protocol. Cheaper code base
> replication, backup and regional redirection and hosting of
> codebases. (Obviously signing jar files will be an important step
> to prevent unwanted codebase mixing -eg a remote codebase attack
> with DNS posioning). Dynamic IP addresses, virtual hosts and fail
> over hosting will work too. What's the price you may ask? For
> proper comparison, URI's must have a strictly restricted character
> set and be normalised EG: legal but escaped characters must be
> unescaped, the scheme must be in lower case, the host must also be
> in lower case, the path is case sensitive (file URL paths on
> Windows must be converted to upper case). Only after
> normalisation is complete can we accurately call hashCode() and
> equals() on URI instances, since this eliminates false negatives.
>
> * Avoid using the underscore (_) character in machine names.
> Internet standards dictate that domain names conform to the
> host name requirements described in Internet Official Protocol
> Standards RFC 952 and RFC 1123. Domain names must contain only
> letters (upper or lower case) and digits. Domain names can
> also contain dash characters ( - ) as long as the dashes are
> not on the ends of the name. Underscore characters ( _ ) are
> not supported in the host name.
>
> * The huge benefit is now we can perform URI string based
> comparison, without relying on a URL Handlers for identity, so
> future URL Handlers will also have the same expected behaviour and
> must conform to standards. This will also have huge performance
> benefits, no longer will class resolution block on DNS calls, nor
> will equals and hashCode comparison rely on DNS resolution.
>
> Currently non conforming URL's can be loaded, such as
> "http://hudson_solaris:9081/nonactivatablegroup-dl.jar", these will no
> longer be supportable with URI.
>
> What do you say? Do I revert to tried and tested URL (the devil we
> know) or do I report a bug against the use of an underscore in the
> hudson_solaris hostname and continue refining the use of URI?
>
> Regards,
>
> Peter.
>
>
>
>
>
RE: PreferredClassProvider: URL and URI
Posted by Christopher Dolan <ch...@avid.com>.
I say file a bug against the underscore. I've fought this battle before and lost...
http://domainkeys.sourceforge.net/underscore.html
Chris
-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: Monday, August 06, 2012 7:39 AM
To: dev@river.apache.org
Subject: PreferredClassProvider: URL and URI
It turns out the recent failures on Solaris x64 hudson are due to an
illegal character in the URI host name string:
Testcase:
testCrossPlatformNormalise(org.apache.river.impl.net.UriStringTest):
Caused an ERROR
Illegal character in hostname at index 13:
http://hudson_solaris:9081/nonactivatablegroup-dl.jar
java.net.URISyntaxException: Illegal character in hostname at index 13:
http://hudson_solaris:9081/nonactivatablegroup-dl.jar
The hostname is incorrectly parsed only as an authority component when
passed to the constructor URI(String str), leading to the errors seen in
failing hudson tests.
So the good news is, it isn't a problem with Solaris x64.
But it does raise some important questions.
But first some background...
The summary of semantic changes:
* Previous releases of Jini & River PreferredClassProvider have
relied upon URL and the calling threads context ClassLoader
(called the parent loader) to determine the correct
PreferredClassLoader. Basically URL resolves to an IP address, so
the ClassLoader was determined by the IP address of the codebase
and the calling threads context ClassLoader.
* We could use URI and the calling Threads context ClassLoader
instead. This means that the PreferredClassLoader would be
determined by the normalised form of the URI and the context
ClassLoader.
The nitty gritty:
* Relying on the IP address probably made sense in the 90's, today
there are issues with virtual hosts, dynamic ip addresses and
maintaining a fixed IP address over time and failover codebase
replication so that the codebase always appears as the same IP
address to clients. You might also imagine that if Jini / River
hits the internet, that NAT and routing would cause some big
problems. This doesn't mean we couldn't continue to use URL and
provide a URL Handler for some new protocol that solves these issues.
* Changing to URI brings some big benefits, but it comes at a
price. The benefits are an added layer of indirection, a
documented standard that can be used to predict ClassLoader
selection reliably, regardless of protocol. Cheaper code base
replication, backup and regional redirection and hosting of
codebases. (Obviously signing jar files will be an important step
to prevent unwanted codebase mixing -eg a remote codebase attack
with DNS posioning). Dynamic IP addresses, virtual hosts and fail
over hosting will work too. What's the price you may ask? For
proper comparison, URI's must have a strictly restricted character
set and be normalised EG: legal but escaped characters must be
unescaped, the scheme must be in lower case, the host must also be
in lower case, the path is case sensitive (file URL paths on
Windows must be converted to upper case). Only after
normalisation is complete can we accurately call hashCode() and
equals() on URI instances, since this eliminates false negatives.
* Avoid using the underscore (_) character in machine names.
Internet standards dictate that domain names conform to the
host name requirements described in Internet Official Protocol
Standards RFC 952 and RFC 1123. Domain names must contain only
letters (upper or lower case) and digits. Domain names can
also contain dash characters ( - ) as long as the dashes are
not on the ends of the name. Underscore characters ( _ ) are
not supported in the host name.
* The huge benefit is now we can perform URI string based
comparison, without relying on a URL Handlers for identity, so
future URL Handlers will also have the same expected behaviour and
must conform to standards. This will also have huge performance
benefits, no longer will class resolution block on DNS calls, nor
will equals and hashCode comparison rely on DNS resolution.
Currently non conforming URL's can be loaded, such as
"http://hudson_solaris:9081/nonactivatablegroup-dl.jar", these will no
longer be supportable with URI.
What do you say? Do I revert to tried and tested URL (the devil we
know) or do I report a bug against the use of an underscore in the
hudson_solaris hostname and continue refining the use of URI?
Regards,
Peter.