Closed rconnamacher closed 11 years ago
+1. just wanted to create the same issue. In another project - lessphp this does work correctly. looking at the source of servlet it's never recompiled:
if (!resources.containsKey(uri)) {
if ("text/css".equals(mimeType)) {
resources.put(uri, new StyleResource(getServletContext(), uri, charset, cache, compress));
} else if ("text/javascript".equals(mimeType)) {
resources.put(uri, new ScriptResource(getServletContext(), uri, charset, cache, compress));
} else {
resources.put(uri, new Resource(getServletContext(), uri, charset, cache));
}
}
return resources.get(uri);
When we upgraded to the latest servlet, the changes in this commit caused our less files to recompile every request. We chose not to use the cache option, because before this commit, the files would only recompile when necessary based on the modified date changing. I do acknowledge there was an issue with the imported file not being detected on the requested file as noted above.
I worked on some updates that will update it to work as follows:
I will create a pull request. Admittedly, Java development is not my primary platform, so feel free to offer critical feedback of any of my code. Hopefully the solution will still be useful, that is, if you agree with my assessment of how it works.
When caching is disabled, changes to the top-level LESS file does correctly cause the CSS to be rebuilt.
However, if that top-level file @imports several other LESS files, changes to those other LESS files do not cause the cache to be rebuilt. Instead, the same compiled CSS continues being output until the top-level file is modified.
It would appear that there is still a cache being saved somewhere, and it is simply rebuilt when the top-level file is modified. Instead, with cache disabled it should always rebuild the output whether the top-level file has been modified or not.
Following is the relevant part of our web.xml: