Issue 1:
Paul Middelkoop opened SPR-8494 and commented

I have @Configuration Spring configuration with @EnableTransactionManagement and a @ImportResource. In the imported resource I use cache:annotation-driven/. This results in: java.lang.IllegalArgumentException: Class name [null] is not a known auto-proxy creator class

When I use <tx:annotation-driven /> instead of @EnableTransactionManagement everything works fine.

Problem also exists in nightly build of June 27th.

Complete stacktrace:

Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [applicationContext.xml]; nested exception is java.lang.IllegalArgumentException: Class name [null] is not a known auto-proxy creator class

at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:412)

at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)

at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)

at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174)

at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:209)

at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:180)

at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsFromImportedResources(ConfigurationClassBeanDefinitionReader.java:293)

at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass(ConfigurationClassBeanDefinitionReader.java:118)

at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitions(ConfigurationClassBeanDefinitionReader.java:105)

at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:264)

at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigurationClasses(ConfigurationClassPostProcessor.java:199)

at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:175)

at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:617)

at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:446)

at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:102)

at org.springframework.test.context.support.AbstractGenericContextLoader.loadContext(AbstractGenericContextLoader.java:1)

at org.springframework.test.context.TestContext.loadApplicationContext(TestContext.java:124)

at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:149)

... 24 more

Caused by: java.lang.IllegalArgumentException: Class name [null] is not a known auto-proxy creator class

at org.springframework.aop.config.AopConfigUtils.findPriorityForClass(AopConfigUtils.java:140)

at org.springframework.aop.config.AopConfigUtils.registerOrEscalateApcAsRequired(AopConfigUtils.java:113)

at org.springframework.aop.config.AopConfigUtils.registerAutoProxyCreatorIfNecessary(AopConfigUtils.java:74)

at org.springframework.aop.config.AopNamespaceUtils.registerAutoProxyCreatorIfNecessary(AopNamespaceUtils.java:58)

at org.springframework.cache.config.AnnotationDrivenCacheBeanDefinitionParser$AopAutoProxyConfigurer.configureAutoProxyCreator(AnnotationDrivenCacheBeanDefinitionParser.java:109)

at org.springframework.cache.config.AnnotationDrivenCacheBeanDefinitionParser.parse(AnnotationDrivenCacheBeanDefinitionParser.java:67)

at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)

at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1414)

at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1404)

at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:184)

at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:140)

at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:111)

at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)

at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)

... 41 more

Affects: 3.1 M2

Issue Links:

#13058 @EnableTransactionManagement does not handle APC escalation ("duplicates")

#13375 Unable to use @EnableTransactionManagement along with <cache:annotation-driven /> ("is duplicated by")

Issue 2:
Hannes Schmidt opened SPR-8662 and commented

The basic problem is that UriTemplate first substitutes the template variables into a single string and then encodes that string as a whole using URIUtils. This simply can't work reliably because the substitution could produce a string that is impossible to parse using a regular expression for URLs. For example, the following template

http://foo.com/things/{thingId}

with the following value for thingId

a/b

produces the following string after substitution

http://foo.com/things/a/b

When URIUtil does not encode the / between a and b because it takes the slash literally. This is what I would expect in this case:

http://foo.com/things/a%2Fb

The reason we have URL-encoding is so we can embed any string into a URL without breaking it. But we need to encode the embedded string BEFORE we embed it. We can't expect URIUtils to be able to fix a URL that we broke by embedding an unencoded string.

Now, depending on where we embed a string into a URL certain characters loose their special meaning. The slash, for example, has no special meaning in the query part. If we want to produce URLs without redundantly encoded parts, we need to take the context into account. Nevertheless, it is always safe to encode all special characters in each embedded string and that would be a simple fix.

Affects: 3.0.5

Issue Links:

#13050 UriTemplate doesn't encode query parameters

INT-2569 Refactor HttpOutboundGateway to mitigate breaking changes due to UriTemplate changes in Spring 3.1