Hi I committed on myfaces-commons-resourcehandler module on trunk an alternative solution for this issue. It is still not complete, so the idea is discuss it. See:
https://issues.apache.org/jira/browse/MFCOMMONS-33 >From previous discussion, on AdvancedResource handler we have: a. relative paths between resources (css files referencing images without using #resource['..']) b. caching resources in the client (disabled if ProjectStage == Development) c. GZIP compression and local cache in tmp dir (disabled if ProjectStage == Development) d. i18n (supporting country code and language). We had the following proposals: 1. reutilize resource information to prevent unnecessary calls to getResource() (shared ResourceCache). 2. Alternate xml file 3. Make it work with suffix mapping. 4. Add a SPI interface to delegate .xml resource scanning. 5. Use content delivery network (CDN) to load known javascript or other resource files like jQuery or prototype. The objective is provide a solution for all those wanted features. The most important one is number 3. (make it work with suffix mapping), because it limits the scope where a. (relative paths between resources) could be applied. Use a parse on some files it is not a very good solution, so I tried to found an alternative. The most simple one is use a filter that just do the "resource handling" part, just like FacesServlet does. So with suffix mapping you only need to add this on web.xml file: <filter> <filter-name>Faces Filter</filter-name> <filter-class>org.apache.myfaces.commons.resourcehandler.filter.ResourceHandlerFilter</filter-class> </filter> <filter-mapping> <filter-name>Faces Filter</filter-name> <url-pattern>/javax.faces.resource/*</url-pattern> </filter-mapping> and that's it. In this way, there is no need to any parser, just put the files on a library, register it on the xml file. If you are using prefix mapping for Faces Servlet, you will not need that entry, because everything will be handled from Faces Servlet. With this solution, javascript libraries like dojo that loads files or have css resources with url(...) entries will work without any changes. I have seen this issue: https://issues.apache.org/jira/browse/MFCOMMONS-30 Change URL management of Advanced JSF 2 ResourceHandler The idea was use this http://{server}[:port]/{appPath}/javax.faces.resource/{locale}/{libraryName}/[resourceName] Unfortunately, this syntax is ambiguous, because it is not possible to identify if the request should be handled by the default algorithm or by the "extended" ResourceHandler. So I tried this one on ExtendedResourceHandler: http://{server}[:port]/{appPath}/javax.faces.resource/$/{locale}/{libraryName}/[resourceName] The first $ caracter says this extension should be handled by the ExtendedResourceHandler. We can go further and allow this notation: http://{server}[:port]/{appPath}/javax.faces.resource/$$/{libraryName}/[resourceName] In this way there is no ambiguity, and we don't need to force locale to be output. This could be possible too: http://{server}[:port]/{appPath}/javax.faces.resource/$$$/[resourceName] But that it is not really necessary at all. The proposed code still does not contains the options for GZIP compression, because the previous algorithm does not take into account what happen on concurrent requests (two threads modifying the same file at the same time). I did an algorithm for sandbox for JSF 2.0 s:roundedPanel. It uses an application scope map and some synchronized blocks to ensure only one thread writes the file. Exactly the same pattern works in this case, so the only thing we need to do is refactor that code and put it here. Does that sounds good? if no objections commit the proposals here soon. regards, Leonardo Uribe
