PropertiesLoaderSupport no longer works with XML-formatted property files when they're loaded as a FileSystemResource. [SPR-9043]

[spring-projects-issues]

matt opened SPR-9043 and commented

In Spring 3.0.6, when detecting whether a property file was a Java 5 xml-formatted property file, the code looked like this:

String filename = null;
try {
	filename = location.getFilename();
} catch (IllegalStateException ex) {
	// resource is not file-based. See SPR-7552.
}

if (filename != null && filename.endsWith(XML_FILE_EXTENSION)) {
	this.propertiesPersister.loadFromXml(props, is);
}

In Spring 3.1, that code looks like this:

String filename = (location instanceof AbstractFileResolvingResource) ?
		location.getFilename() : null;
if (filename != null && filename.endsWith(XML_FILE_EXTENSION)) {
	this.propertiesPersister.loadFromXml(props, is);
}

The problem is, FileSystemResource doesn't extend AbstractFileResolvingResource. So if an xml-formatted properties file is loaded as a FileSystemResource, it will not be loaded properly.
I don't know if the right answer is to make FileSystemResource extend AbstractFileResolvingResource (which seems to make sense) or to change the "location instanceof AbstractFileResolvingResource" above to catch both cases -- AbstractFileResolvingResource or FileSystemResource.

---

Affects: 3.1 GA

Referenced from: commits 57851de, 1d9d3e6

1 votes, 2 watchers

[spring-projects-issues]

Javier Andrade commented

I'm having the same issue which is preventing me from migrating to Spring 3.1. It seems like XML properties files only work when I use "classpath:" which is not an option for me. I also can't migrate to a classic properties file. If I specify a URL location like "file:///path", it still doesn't work since it resolves to a FileSystemResource.

[spring-projects-issues]

Juergen Hoeller commented

Since it wasn't clearly defined what Resource.getFilename() would actually return if the underlying resource type does not have a natural filename, I've now taken that step and clarified that it consistently returns null in that case (in contrast to the previous implementation detail in AbstractResource which threw an IllegalStateException). This also simplifies PropertiesLoaderSupport's use of the getFilename() method which is dealing with null filenames anyway and does not require any extra checking now.

Juergen