Classpath resources should not be accessed by filesystem paths

Hello,

I have found a wildfly compatibility issue with version 4.1.0. While I know that wildfly is not supported and everything seems to work just fine on jetty (and propably tomcat too), I think this issue might cause problems on supported platforms in the future.

So, in 4.1.0, the "system" files have been moved into idp-conf-impl-4.1.0.jar as is stated in the release notes.

Now wildfly is unable to load them:

2021-04-07 16:05:23,705 - 172.16.0.1 - ERROR [org.apache.velocity.loader:351] - ResourceManager: unable to find resource 'client-storage/local-storage-read.js' in any resource loader.
2021-04-07 16:05:23,706 - 172.16.0.1 - ERROR [org.apache.velocity.directive.include:245] - #include(): cannot find resource 'client-storage/local-storage-read.js', called at /client-storage/client-storage-read.vm[line 26, column 9]
2021-04-07 16:05:23,707 - 172.16.0.1 - ERROR [net.shibboleth.idp.profile:-2] - Uncaught runtime exception
java.lang.IllegalStateException: Exception occurred rendering view net.shibboleth.ext.spring.velocity.VelocityView: name '/client-storage/client-storage-read'; URL [/client-storage/client-storage-read.vm]
{{ at deployment.login.war//org.springframework.webflow.mvc.view.AbstractMvcView.render(AbstractMvcView.java:208)}}
Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'client-storage/local-storage-read.js'
{{ at deployment.login.war//org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:461)}}

The reason seems to be this:

2021-04-07 14:49:17,008 - - DEBUG [net.shibboleth.ext.spring.velocity.VelocityEngineFactory:321] - Resource loader path 'classpath:/net/shibboleth/idp/views' resolved to file '/opt/wildfly_base/tmp/vfs/deployment/deployment36580d67cdade32c/idp-conf-impl-4.1.0.jar-e7c5347820a4d3d7/contents/net/shibboleth/idp/views'

"classpath:/net/shibboleth/idp/views" has actually been resolved to a path in the file system where apparently wildfly has unpacked the idp-conf-impl-4.1.0.jar. But only partially, most of the files are missing (i.e. client-storage/local-storage-read.js). I'm not sure if wildfly is to blame here. I guess the wildfly folks did not expect someone to access classpath resources via a file system path. And I suspect you did not expect the jar files inside the war to be unpacked.

Compare the same situation on Jetty:

{{2021-04-07 14:57:12,183 - - DEBUG [net.shibboleth.ext.spring.velocity.VelocityEngineFactory:326] - Cannot resolve resource loader path 'classpath:/net/shibboleth/idp/views' to filesystem, will use SpringResourceLoader
}}

Things seem to go wrong here: https://git.shibboleth.net/view/?p=spring-extensions.git;a=blob;f=src/main/java/net/shibboleth/ext/spring/velocity/VelocityEngineFactory.java;hb=65dc4c3ae3548e75098596f555973b6811a3cf01#l318

This check
{{ // Will fail if not resolvable in the file system.
final File file = resource.getFile();
}}

Does not (necessarily) fail on  wildfly for classpath:// resources. So I guess the paths should be filtered so that classpath:// paths would never be accessed via the file system.

Maybe Spring is to blame here. I really see no point in accessing classpath resources via the file system. It might be more efficient but this kind of efficiency should be left to the runtime environment entirely. I suspect this is what wildfly is trying to accomplish.

Sorry to bother you. I know that, by using an unsupported platform, I'm on my own. It still might be interesting.