On 12-02-10 01:14 PM, Greg Reddin wrote:
On Fri, Feb 10, 2012 at 10:32 AM, Nicolas LE BAS<[email protected]> wrote:
Thanks for identifying this issue, but for some reason the attachement
didn't come through to the list. Could you maybe open a JIRA issue for it:
https://issues.apache.org/jira/browse/TILES
I'm pretty sure the list strips attachments. So Jira is the way to go.
Thanks,
Greg
Well, I've looked into it a bit. I'm shy of fixing this on 2.2 without
Gordon's assistance, since he's the one with the test case.
However the problem breaks down to our accessing tiles.xml through URLs,
which is flawed on several aspects:
- the primary purpose of the java.net.URL objects are to access remote
files, but tiles.xml are usually not remote. A remote tiles.xml would
look like a security risk to me.
- when we use an URL to access a local file, it opens the file even when
it could do without (that's Gordon's issue). It may look like a JVM bug,
but actually it isn't: URLs must provide a uniform behaviour accross
protocols (including failure modes).
- we do only 3 things with these URL objects: calling getInputStream and
getLastModified, and manipulating the path for i18n. The path
manipulation happens through several "util" classes (URLUtil and
LocaleUtil), which breaks encapsulation and makes maintenance more
difficult.
These are minor design flaws. We can work around them, but I'd still
like to fix them at some point in the future. That would involve
replacing the URLs by a "ApplicationResource" abstraction. That would
help providing a clean solution to Gordon's issue, and encapsulate the
naming conventions we use for internationalization. This new interface
would have to go into tiles-request-api, because it is created by
ApplicationContext.getResource(...).
I think I'll create a JIRA issue for that. I wonder about when to fix
it. What do you think?
Nick
