Hi A patch has been provided to improve ResourceHandler performance in situations when the required resource is inside a jar file. See:
https://issues.apache.org/jira/browse/MYFACES-3586 This patch opens an old discussion about what should be done by ResourceHandler and what should be let to other external tools. In few words, the patch "suppose" that all resources handled by ResourceHandler are static, and it wants to put a cache, to prevent all necessary calculation involved in extract the resource from the jar file (or war file when the application is not extracted) and in that way improve application scalability, because it exchanges "CPU consumption" with "Memory", which is ok in this case because files are relatively small and open a jar file over and over to calculate the same stuff becomes expensive. In cases like this, usually it is possible to setup the server to deal with this. For example, Tomcat has some configuration params (cacheMaxSize/cachingAllowed) to configure this part. Also, it provides other config params to set up gzip compression (compression/compressionMinSize/noCompressionUserAgents/compressableMimeType). Long time ago, we discussed about create a module in MyFaces Commons, to create a custom ResourceHandler implementation. Some experiments where done to provide for example gzip compression, as well with other useful features. But in that discussion, it was mentioned that things like gzip compression should not be done there, because this is already done in other places, so in practice we are duplicating work in this part, so we just removed that code and let that discussion for later. But going back to the original problem, there are good reasons to do static caching or gzip compression inside ResourceHandler: - ResourceHandler knows which resources are static and which ones are not, so the necessary logic can be put there, and what is more important, can be customized and be aligned with JSF spec. - Since the cache is inside the server, it uses the memory used by the JVM. With an external module like with an Apache 2.x server, the reserved memory for caching is not shared with the JVM, so memory tuning becomes a little bit complex. - With a good design, it is possible to save some buffers in this part, or do things like create temporal files and prevent the jar opening or compress the same file with gzip algorithm over and over. - Suffix mapping ( use .jsf as extension for resources ) does not play well with external tools, which usually expect files ending with .js, .css, .png and other extensions. In the other side, there are disadvantages: - There exists other solutions that are faster and better, because they are well known and already tested, so why bother for this? - More code to maintain. - MYFACES-3586 needs more work to be included, because not all resources handled by ResourceHandler are static (for example the image rendered by a captcha component needs to be generated dynamically). In conclusion, we need to clarify the community position about if it is worth to do it or not, before accept or not a modification like MYFACES-3586. For now, and to be consistent with previous discussions, the patch will not be included for now. Suggestions are welcome. regards, Leonardo Uribe
