XML bean definition "import" directive doesn't work with custom resource loader [SPR-5762]

[spring-projects-issues]

Stefan Podkowinski opened SPR-5762 and commented

I've written a custom resource loader that is supposed to handle protocol "hdfs://" and registered the loader with the XmlBeanDefinitionReader as follows:

XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(context);
reader.setResourceLoader(resourceLoader);

Within my application, resolving resources with the "hdfs://" prefix is working perfectly fine. So I was rather surprised to see the following import directive fail:

<beans>
<import resource="hdfs:///meta/schemes/common.xml"/>
</beans>

The following exception will occur:

Exception in thread "main" org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from relative location [hdfs:///meta/schemes/common.xml]
Offending resource: file [/home/test/workspace/test/application-context.xml]; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from file [/home/test/workspace/test/hdfs:/meta/schemes/common.xml]; nested exception is java.io.FileNotFoundException: /home/test/workspace/test/hdfs:/meta/schemes/common.xml (No such file or directory)
at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:76)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.importBeanDefinitionResource(DefaultBeanDefinitionDocumentReader.java:201)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseDefaultElement(DefaultBeanDefinitionDocumentReader.java:147)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:132)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:92)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:475)

The problem here is that the DefaultBeanDefinitionDocumentReader.importBeanDefinitionResource() method will use ResourcePatternUtils.isUrl() to determine if the path is relative or not. Finally if the path is a valid url or not will be based on the outcome of valuating new URL(resourceLocation). In case a MalformedUrlException is thrown, it will return false and a relative path is build in importBeanDefinitionResource().

The thing to note here is that a MalformedUrlException thrown in the java.lang.net.URL constructor will not indicate a syntactically incorrect url, but only an unkown protocol.

---

Affects: 3.0 M3

Attachments:

• SPR-5762.ZIP (2.78 kB)

Issue Links:

• Cannot import bean definitions using classpath*: resource location [SPR-6366] #11032 Cannot import bean definitions using classpath*: resource location ("is duplicated by")
• location parsing might incorrectly rely on the URL API [SPR-6332] #10998 location parsing might incorrectly rely on the URL API

Referenced from: commits bcc6413

[spring-projects-issues]

Costin Leau commented

Stefan, I've committed a fix which uses URIs to detect whether a location is absolute or relative. This avoids the schema handler check done by URLs.
Please let us know if the latest trunk solves your issue.

Thanks.

[spring-projects-issues]

Radim Tlusty commented

It seems, that this correction have damaged usage of 'classpath*:' URLs.

I think, that the issue is in DefaultBeanDefinitionDocumentReader class. In 3.0.0.RC1 there was used call 'ResourcePatternUtils.isUrl(location)', in 3.0.0.RC2 it's changed and I think, that it's related to this correction.

When the classes are unpacked, it leads to transformation of classpath* URL to file URL, which causes the problem.

I will attach simple test case, which works in 3.0.0.RC1, but fail on 3.0.0.RC2.

[spring-projects-issues]

Radim Tlusty commented

Maven project with test case, like I have described.
You can switch the spring.version property in POM to see the behavior.

[spring-projects-issues]

Costin Leau commented

Radim, thanks for the report - the classpath/classpath*: prefix was overlooked. The problem should be now fixed (through #11032). Could you please give the snapshot a try? Thanks.