PathMatchingResourcePatternResolver Questions

[sinclair.bain]

Hi,
I have been running some 'tests' against the <PathMatchingResourcePatternResolver> class .
The intent is for the 'pattern resolver' to locate resources in a jar file.
The jar file is placed on the classpath. The jar contains the following entry:

• /a/b/c/abc.txt.

i.e. there is a file abc.txt in the a/b/c directory.
The <PathMatchingResourcePatternResolver> instance is created via the default constructor.
The 'test' exercises the #getResources(String locationPattern) method:

    _resolver.getResources(locationPattern);

The following are the outcomes (with the <locationPattern>s in quotes):

• Success (i.e. the getResources() method returns/locates the abc.txt file)
  [list:04f948b386]
  "classpath:/a/b/c/abc.txt"
  "/a/b/c/abc.txt"
  "/a/b/"

No resources found

• "classpath*:/a/b/c/abc.txt"
  "classpath*:/a/b/**/abc.txt"

FileNotFoundException thrown

• "/a/b/**/abc.txt"
  "classpath:/a/b/**/abc.txt"

[/list:u:04f948b386]
Can this 'pattern resolver' locate resources located in a jar file on the classpath when they are identified using a pattern?

Tools: Windows XP; Spring 1.1; Sun Java 1.4.2_03; IDEA 4.5

P.S. I have the test code available.

[Alef Arendsen]

Hmmm, I've written a small test myself and ran into the same problem. It seems it's some kind of classloading issue.

To be honest, I'm no classloading expert, so I guess somebody else will have to help out here. There seems to be a difference between the contextclassloader associated with the current thread and the classloader I'm getting from e.g. java.lang.Class. This I knew, but I can't figure out why the first line from the following code passes and the second lines fails! The second line is used in the ResourcePatternResolver (context classloader is used everywhere in Spring IIRC)

// pass!
assertNotNull(Class.class.getResource
    ("/org/springframework/core/io/support/classpathResource.txt"));
// fail!
assertNotNull(Thread.currentThread().getContextClassLoader().getResource("/org/springframework/core/io/support/classpathResource.txt"));

Alef

[Juergen Hoeller]

Well, PathMatchingResourcePatternResolver's main feature is to matching file paths against the file system, with file path expressions that contain "*" or "**" wildcards. This will only work for resource locations that can actually be resolved as files in the filesystem.

"classpath*:" has special treatment here: It delegates to ClassLoader.getResources - we cannot search through a file system there. Consequently, no file patterns are supported in such an expression. You will get all files with the given classpath resource name, though, usually found at the same location in multiple jar files.

So these ones cannot work at all:

"classpath*:a/b/**/abc.txt"
"classpath*:/a/b/**/abc.txt"

But this one will:

"classpath*:a/b/c/abc.txt"

This one is supposed to work too, but unfortunately we didn't check for the leading slash there (I've just fixed this, to be part of 1.1.1):

"classpath*:/a/b/c/abc.txt"

The following ones will work if the classpath location can be resolved in the file system (else you'll get a FileNotFoundException):

"classpath:a/b/**/abc.txt"
"classpath:/a/b/**/abc.txt"

Juergen

[sinclair.bain]

Thanks for your help.

I would just like to clarify the java doc for the PathMatchingResourcePatternResolver:

There is special support for retrieving multiple class path resources with the same name, via the "classpath*" prefix. For example, "classpath*:/beans.xml" will find all beans.xml files in the class path, be it in "classes" directories or in JAR files. This is particularly useful for auto-detecting config files.

I would like to have components define an "applicationContext.xml" file as needed. Then at a sub-system level (application layer) define a "beanRefContext.xml" which will aggregate the component "applicationContext.xml" files using a technique such as:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans 
	PUBLIC "-//SPRING//DTD BEAN//EN" 
	"http&#58;//www.springframework.org/dtd/spring-beans.dtd">
 
<beans>

	<!-- define an aggregate application context -->
	<bean id="com.panacya.platform.kernel" 
	        	class="org.springframework.context.support.ClassPathXmlApplicationContext">
		<constructor-arg>
			<list>
				<value>com/panacya/platform/kernel/**/applicationContext.xml</value>
			</list>
		</constructor-arg>
	</bean>


</beans>

The aim is to avoid the need to update this aggregating context file when new component "applicationContext.xml" files are created/added. However it would appear that if those components application contects are packaged in jar files then this technique will not work - according to your comments. However the javadoc would appear to state otherwise.

Can you clarify whether this is possible ?

[Colin Sampaleanu]

You can't mix the wildcards and the classpath*: (aggregation) prefix. But you can certainly do the automatic aggregation as long as the applicationContext.xml files are all at the same path, i.e. there are no wildcards in the resource path itself:

<list>
  <value>classpath*&#58;com/whatever/standard/package/applicationContext.xml</value>
</list>