Better path matching support in PathMatchingResourcePatternResolver [SPR-469]

[spring-projects-issues]

Oliver Hutchison opened SPR-469 and commented

It would be great if the path matching feature of PathMatchingResourcePatternResolver worked for all resources regardless of whether they are located on the file system or contained in jars.

For instance I'd love to be able to use the following kinds pattern even when my mapping files are packaged into jars:

classpath:/mappings//*.hbm.xml classpath*:/mappings//*.hbm.xml

---

Affects: 1.1.2

Attachments:

• PathMatchingResourcePatternResolverImprovment.patch (17.80 kB)

[spring-projects-issues]

Oliver Hutchison commented

Attached is a patch which resolves (in my simple environment) this issue. I've also includes a VERY rough test case.

NOTE: I have done no testing of this code in any app server environments (my use case is with a JWS deployed rich client app) so I've got no idea if this will work when the classpath jars may actually be inside another jar/war/ear. Assuming the app server installs a JarURLConnection handler that supports nested jars (the standard Java impl. does not) I can't see any reason why this shouldn't work but then who knows with app servers...

[spring-projects-issues]

Colin Sampaleanu commented

I've taken only a brief look at this patch, but I think it will fail in WebLogic for example. I see the patch relies on matching a JarUrlConnection, which matches a URL of the form:

jar:http://www.foo.com/bar/baz.jar!/COM/foo/Quux.class

As per this old post of mine from 2001 to the log4j list, http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4j-dev@logging.apache.org&msgNo=721

WebLogic (at least older versions anyways, I haven't worked with 7 and 8 much) will expose classpath resources coming from a jar file via a registered 'zip' protocol handler, with URLs looking like:

zip:a/b/c/d/baz.jar#/COM/foo/Quux.class

Somewhat similar, but ultimately handled by a different mechanism, I think...

Colin

[spring-projects-issues]

Colin Sampaleanu commented

So I am of a mixed mind as to whether it is better to work in some cases where something is coming from a JAR, or in none. Generally I like consistency. The other concern is possibly with the speed, since this is reading entries from inside a zip file, although I guess whether that's a concern is really a function of the actual use.

[spring-projects-issues]

Oliver Hutchison commented

Thanks Colin, I suspected that there could be problems with nested Jars, however, I'd argue that this is still a feature worth having regardless of whether it works in Weblogic et. el. or not. It should work fine in Servlet containers, it works fine in standalone and JWS apps, it should work in app servers that do things properly and install a JarURLConnection that handles nested jars or that explode contents of archives to temporary directories

As far as consistency is concerned IMO the current implementation is hardly consistent. For instance - I've had the situation where my application works fine in development, tests all work etc.. so I deploy the app using JWS (which means I have to put everything into Jars) and it falls over as the path matching no longer works.

Also I didn't find that the performance was that bad - aprox 0.5 second to search "classpath*:org/apache/*/.class" (>6,000 classes) on my 2GHz P4. I suspect that this is mainly going to be uses on app startup anyway.

[spring-projects-issues]

Juergen Hoeller commented

I've added support for path matching in jar files, following Oliver's suggestion and prototype. I've extended it a bit to work with both "classpath:" and "classpath:"; path matching in the file system and path matching in jar files works with both now. So a pattern like "classpath:META-INF/*-context.xml" is perfectly valid now, as long as the "META-INF" directories can be resolved in the file system or in jar files.

It would be great if you could grab the new version of PathMatchingResourcePatternResolver from CVS and test it against various scenarios! I've tried all sorts of combinations on Windows, standalone and with Tomcat and Resin. It would be particularly good to test on Linux (standalone and with Tomcat) and on WebLogic.

Juergen