Resources loaded by the JPPF classloader via findResource(), findResources(), etc .... are stored on the node's file system in a flat structure.
The names of the resources in this cache are currently computed using temproary unique names.
This causes a lot of grief for some framework (e.g. Spring, EclipseLink) who rely on the accuracy of the URL(s) returned by findResource() and findResources().
Some need the full path as specified in the parameter as resource name, other's need to check the file extension, etc ....
For instance, testing a small EclipseLink application, I found out the following:
- EclipseLink needs a number of xml files in META-INF, e.g.META-INF/persistence.xml
- the node's JPPF classloader, after downloading this file from the client, stores it in a temporary location on the node's file system: <tempdir>/<some_tmp_file_name>.tmp
- this causes EclipseLink to fail to process the file, as it is looking for "META-INF/persistence.xml" in the file URL returned by the class loader
So basically to fix this, we need to redesign the way files are stored in the class loader's resource cache, so that it reflects the actual path specified in the class loader's method call.
I managed to refactor the cache to accomplish this, however additional testing will be required, and we also need to do our best to cleanup the stored files when the ResourceCache object is garbage collected, or the JVM is terminated.