On 01/14/2016 02:07 AM, Lukasz Lenart wrote: >> - #getResource(path) and #getResources(path) are used for non localized>> >resources. Tiles uses them to inventory the tiles.xml files at startup, like
>> >here:>> >https://github.com/apache/tiles/blob/TILES_3_0_X/tiles-core/src/main/java/org/apache/tiles/factory/BasicTilesContainerFactory.java#L220
>> >or here:>> >https://github.com/apache/tiles/blob/TILES_3_0_X/tiles-extras/src/main/java/org/apache/tiles/extras/complete/CompleteAutoloadTilesContainerFactory.java#L203
> Those methods return ApplicationResource, how should I construct it?
> Right now I'm doing it like this for all tiles*.xml definition files,
> should I distinct them based on a suffix ("en", "pl")?
>
>
https://github.com/apache/struts/pull/73/files#diff-a4ef02a35b4a5838b0cc73fa5e6236f9R113
>
I think it will be OK. There is some logic in Tiles (BaseLocaleURLDefinitionDAO.setSources) that will strip the locale suffix and realize that tiles_en.xml and tiles.xml are related. You may run into trouble if you're using more underscores in your filename, though (like tiles_myapp_en.xml and tiles_myapp.xml).
On 01/14/2016 02:07 AM, Lukasz Lenart wrote:
Because I want to have wildcard support without using Tiles wildcard servlet which is based on Spring https://github.com/apache/struts/pull/73/files#diff-a4ef02a35b4a5838b0cc73fa5e6236f9R45
OK. I don't know what's wrong with spring.I can see a couple of things wrong with the implementation you're proposing, though: - The existence of an ApplicationResource instance implies that the file exists. I think that your StrutsWildcardServletApplicationContext fullfills that requirement. Therefore you shouldn't have to test for the existence of the file in getInputStream(). Tiles certainly expects this method never to return null.
- Reliance on the existence of a physical File: many servlet containers have issues with that, depending their configuration. I can think of tomcat, jetty, jboss, weblogic, websphere (you can configure tomcat and jetty for not unpacking the wars, and I think the last 3 use a Virtual File Structure). That's what I like the most with the spring-based solution: those guys have ironed out this kind of problems :)
Overall I think URLApplicationResource is a better fit for you than your custom implementation, since the XWorks ResourceFinder returns URLs.
Hope this helps. Nick.
