Re: [ANNOUNCE] Tiles Request 1.0.4 test build available

[mck <mc...@apache.org>]

> I like the way you cleaned up the code, however I'd like to do two
things before I vote:

 ping.ave you any time to look into this so we can progress on the
release?

> - test if there's a warning message when the file name contains no underscore.

If the filename contains no underscore then prefixIndex is -1 and locale
becomes Locale.ROOT (see PostfixedApplicationResource)

This is verified with PostfixedApplicationResourceTest.


> - check if somehow Tiles rely on the file name matching the locale name exactly. In that case, the "closest
> available locale" solution would be a problem in itself. I'd like especially to look for calls to PostfixedApplicationResource(String,Locale).

Anywhere you look for a resource and manually specify the locale then
the underscore in the resource name has no meaning.
I understand your concern of the mismatch between a manually specified
locale in one place and then a lookup and closest match in another
place, but i cannot see where this would be done or in what way it's a
problem.


~mck

Re: [ANNOUNCE] Tiles Request 1.0.4 test build available

[Nicolas Le Bas <ma...@nlebas.net>]

On 14-04-28 02:53 AM, mck wrote:
> ping.ave you any time to look into this so we can progress on the release?
Yes, I'm basically satisfied with my findings.
I've merged your changes into trunk and I'll commit a test case tonight.

Selenium is broken since firefox 23, I've had to switch to google 
chrome; I hope it won't be an issue.

Nick

Re: [ANNOUNCE] Tiles Request 1.0.4 test build available

[mck <mc...@apache.org>]

> Suppose for some reason, the system decides that en_GB is a valid 
> locale, but should actually be called en_UK as the closest available.


The closest match will always be found by dropping variant first, and
then by dropping region.

So if en_GB is valid, so either locales en_GB or en will be used.

In the example you describe any resource file will be loaded with
closest match locale "en", and both requests using en_GB and en_UK will
use this resource.

~mck

Re: [ANNOUNCE] Tiles Request 1.0.4 test build available

[Nicolas Le Bas <ma...@nlebas.net>]

Hi again, and sorry for the short answer earlier.

I feel the following requires some extra comment on my part:

On 14-04-28 02:53 AM, mck wrote:
>> >- check if somehow Tiles rely on the file name matching the locale name exactly. In that case, the "closest
>> >available locale" solution would be a problem in itself. I'd like especially to look for calls to PostfixedApplicationResource(String,Locale).
> Anywhere you look for a resource and manually specify the locale then
> the underscore in the resource name has no meaning.
> I understand your concern of the mismatch between a manually specified
> locale in one place and then a lookup and closest match in another
> place, but i cannot see where this would be done or in what way it's a
> problem.

I'm thinking of the following hypothetical use case. Please note that 
I'm not entirely sure if this is a real use case, or if it will be in 
the future, and anyway it would not work on req-1.0.3, so 1.0.4 improves 
on things here and deserves to be released.

WEB-INF/tiles-defs_en_GB.xml

Suppose for some reason, the system decides that en_GB is a valid 
locale, but should actually be called en_UK as the closest available.



I'm afraid that the following could occur:
- when a request arrives with locale=en_UK, it doesn't find the en_GB 
file because the locale name doesn't match, therefore the file is not 
read and the tiles-definition is not found.
- when a request arrives with locale=en_GB, it finds the file and we 
build a PostfixedApplicationResource with basename=tiles-def and 
locale=en_GB. But when we try and read the file, the locale has been 
normalized into en_UK (closest available) and the file actually cannot 
be found.
So in the end, that might invalidate the "closest" strategy.


But I couldn't think of an actual locale that would behave that way, so 
I'll raise the issue again when I encounter it, and we can address it at 
that time. Anyway there's an easy workaround :)

Thanks again for your good work and sorry for the delay.

+1 GA