Issue 1:
Ian Sollars opened SPR-8368 and commented

With the splitting of Spring Framework into multiple jar files in v3.0, there are now several files named "META-INF/spring.handlers", "spring.schemas" and "spring.tooling". This is not a problem when running in a normal servlet container, but poses problems when e.g. creating an executable JAR file from a webapp using an embedded web server such as Jetty, or running GWT in "Dev Mode", which uses a custom class loader.

In the former scenario, a typical approach is to use a Maven assembly to extract all .class files from the project dependencies and merge them into one hierarchy, as a way of packaging all the dependencies and the webapp itself into one JAR file.

However, in this case only one copy of "spring.handlers/schemas/tooling" can exist, and so any schemas that are used and /not/ in the one copy cannot be validated. This leads to exceptions such as this one:

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 65 in XML document from class path resource [spring/beans.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'context:annotation-config'.

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:218)

at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseDefaultElement(DefaultBeanDefinitionDocumentReader.java:147)

Other people reporting similar problems can be found at Stack Overflow here and here.

The workaround is to construct your own "custom" version of these three files, merging all the copies into one like so:

//IOUtils and FileUtils come from Apache Commons IOfor(String s : new String[] {"spring.schemas", "spring.handlers", "spring.tooling"}) {

Enumeration<?> e = Test.class.getClassLoader().getResources("META-INF/"+s);

StringBuilder out = new StringBuilder();while(e.hasMoreElements()) {

URL u = (URL) e.nextElement();

out.append(IOUtils.toString(u.openStream())).append("\n");

}

File outf = new File(s);

FileUtils.writeStringToFile(outf, out.toString(), "UTF-8");

}

However, the proper fix would be to use a different file-name for each instance of the schemas/handlers/tooling files. For example, inside "org.springframework.aop-3.0.5.RELEASE.jar/META-INF" you would find "spring-aop.schemas", "spring-aop.handlers" and "spring-aop.tooling".

I'm afraid I'm not sufficiently up-to-speed with the Spring code-base to give you a patch to do this, however a brief investigation shows that "spring.handlers" and "spring.schemas" are specified in org.springframework.beans.factory.xml.PluggableSchemaResolver and DefaultNamespaceHandlerResolver, and that constructors exist for specifying different locations for these files. I hope you find this information useful.

Best regards,

Ian

Affects: 3.0.5

Issue Links:

#13175 META-INF/spring.handlers are hidden resources when running with special isolated ClassLoader, for example as osgi Netbeans plugins or javawebstart ("is duplicated by")

1 votes, 4 watchers

Issue 2:
Vladislav Pernin opened SPR-8256 and commented

The documentation of the great Cache Abstraction feature has some errors :

the namespace declaration http://www.springframework.org/schema/cache/spring-cache.xsd does not exists, replace with http://www.springframework.org/schema/cache/spring-cache-3.1.xsd

duplicate block description of proxy-target-class with the note

the @Cacheable and @CacheEvict annotation key attribute must start with #, as already corrected in the blog http://blog.springsource.com/2011/02/23/spring-3-1-m1-caching/

Affects: 3.1 M1