Owen Cliffe created CXF-4391:
--------------------------------
Summary:
org.apache.cxf.configuration.spring.ConfigurerImpl.initWildcardDefinitionMap
does not fail silently when bean names containing certain characters do not
parse as a regex
Key: CXF-4391
URL: https://issues.apache.org/jira/browse/CXF-4391
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 2.6.1
Environment: Spring 3.0.5 App using Spring integration and SpEL
expressions
Reporter: Owen Cliffe
Priority: Minor
When ConfigurerImpl.initWildcardDefinitionMap scans bean names for wildcard
matches it assumes that all bean definition names containing "*,?,(.+)" are
wildcard beans.
When using Spring integration it is possible in certain places to refer to bean
names via a SPeL expression (e.g referencing channels defined as constants),:
i.e.
{code}
<int:transformer input-channel="#{T(foo.bar.Channels).DEFINED_CHANEL}">
...
{code}
When CXF initialises it tries to parse the uninterpolated value as a regex:
{code}
Caused by: java.util.regex.PatternSyntaxException: Illegal repetition near
index 0
#{T(foo.bar.Channels).DEFINED_CHANEL}
^
at java.util.regex.Pattern.error(Pattern.java:1713)
at java.util.regex.Pattern.closure(Pattern.java:2775)
at java.util.regex.Pattern.sequence(Pattern.java:1889)
at java.util.regex.Pattern.expr(Pattern.java:1752)
at java.util.regex.Pattern.compile(Pattern.java:1460)
at java.util.regex.Pattern.<init>(Pattern.java:1133)
at java.util.regex.Pattern.compile(Pattern.java:823)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.initWildcardDefinitionMap(ConfigurerImpl.java:93)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.addApplicationContext(ConfigurerImpl.java:245)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.setApplicationContext(ConfigurerImpl.java:225)
at
org.apache.cxf.configuration.spring.ConfigurerImpl.<init>(ConfigurerImpl.java:75)
at
org.apache.cxf.bus.spring.SpringBus.setApplicationContext(SpringBus.java:90)
at
org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor.getBusForName(BusWiringBeanFactoryPostProcessor.java:73)
at
org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor.addDefaultBus(BusWiringBeanFactoryPostProcessor.java:189)
at
org.apache.cxf.jaxws22.spring.JAXWS22SpringEndpointImpl.setApplicationContext(JAXWS22SpringEndpointImpl.java:53)
at
org.springframework.context.support.ApplicationContextAwareProcessor.invokeAwareInterfaces(ApplicationContextAwareProcessor.java:106)
at
org.springframework.context.support.ApplicationContextAwareProcessor.postProcessBeforeInitialization(ApplicationContextAwareProcessor.java:85)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:394)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1413)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
{code}
While this is slightly unusual it may also occur elsewhere that SPeL is used -
the context will fail to load whenver CXF does not like the bean name.
I think the default behaviour here should be to catch the Regex Exception and
silently (or log) proceed to the next bean.
in this cases those references
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
