tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas LE BAS <m...@nlebas.net>
Subject Re: tiles 2.2.2 Too many file handles open exception
Date Fri, 17 Feb 2012 16:01:03 GMT
On 12-02-10 01:14 PM, Greg Reddin wrote:
> On Fri, Feb 10, 2012 at 10:32 AM, Nicolas LE BAS<mail@nlebas.net>  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

Mime
View raw message