Using multiple classloaders with FileResolver can cause caching issues

[Jotschi]

Issue

The fileresolver will currently locate and unpack resources using the currently active classloader. The found resource will be extracted and placed in a cache directory. This mechanism is however not taking into account that the classloader can resolve different resources for the same given fileName/path. The fileresolver will currently return the wrong content once the resource has been cached once.

Mitigation

I suggest to prepend a id,key that is classloader specific to the cache directory so that the cache is working correctly when using multiple classloaders. I'm not yet sure what id to use since ideally the cache should survive a restart of the JVM.

[vietj]

that would be indeed more correct but looks complicated to achieve. It does not seem there is a good universal key for classloaders, the closest thing would be to sort and compute a hash of the URL returned by a URLClassLoader.

[vietj]

perhaps we could make the file resolver an SPI and allow anyone to provide its own file resolver for such custom cases ?

[Jotschi]

A custom fileresolver would be ideal I guess. In that case one could also for example write a S3 file resolver.

In my case the resolver could understand the different classloaders and load a key from the classloader that could be included in the cache key.

[vietj]

I think the resolver would provide its own cache key for the file that might include any attribute from the back-end

[pmlopes]

I believe caches don't survive jvm restarts as the root directory is an UUID which is random at start.

I also think we should reduce the use of classloaders (think jpms) and making the resolver an SPI is probably a good idea.