2016-01-16 20:16 GMT+01:00 Nicolas Le Bas <m...@nlebas.net>: > 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).
I think I finally got how it works, thanks! > 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. Not everybody is using it, and it conflicts with existing versions in users' applications. Anyway having whole spring-core with all the dependencies is a bit overwhelming ;-) > 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. Yeah... I see your point, you are right, but for now I am going to leave it as is, it will be part of incoming BETA release so we will have time to fix this. Thanks a lot for all your support! -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/
