Matthias Dietl opened SPR-14268 and commented

As far as i can see, there is no way to manually update the cache of the CachingResourceResolver. As soon as one file is cached, the CachingResourceResolver resolves it from its cache.

In our case, we delete a resource from time to time on the filesystem to trigger a 404-gateway - this does not work because it is cached and Spring tries to resolve the cached resource (which does not exist anymore) which leads to an error.

We've circumvented this by overriding the resolveResourceInteral-Method of the CachingResourceResolver like this:

@Override
protected Resource resolveResourceInternal(final HttpServletRequest request, 
               final String requestPath,
               final List<? extends Resource> locations, 
               final ResourceResolverChain chain) {
    final String key = RESOLVED_RESOURCE_CACHE_KEY_PREFIX + requestPath;
    final Resource resource = this.getCache().get(key, Resource.class);
    try {
        if (resource != null && !resource.getFile().exists()) {
            this.getCache().evict(key);
        }
    } catch (final IOException e) {
        LOG.trace("Error while reading resource", e);
    }
    return super.resolveResourceInternal(request, requestPath, locations, chain);
}

This works but isn't very elegant; could there be a better way to solve this, mabye directly in the framework?

Affects: 4.1.7

1 votes, 4 watchers

Comment From: spring-projects-issues

Brian Clozel commented

Hi Matthias Dietl

What error are you avoiding with this code? Is there an exception being thrown? Is the response still a 404 as it should be, or something else? Could you share some more details about that error?

Are those resources deleted "out-of-band", by a process separate from the Spring application? Could you directly use the Cache in CachingResourceResolver and remove entries from it as resources are being deleted?

I've considered adding some existence check in CachingResourceResolver but all of those require I/O ops with the file system; this should cause a significant performance penalty for all requests, since it requires reading the file attributes for each request.

Comment From: bclozel

We don't have enough information about the use case behind this issue. Community members can of course reopen this issue with more information.