cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Owen Cliffe (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-4391) org.apache.cxf.configuration.spring.ConfigurerImpl.initWildcardDefinitionMap does not fail silently when bean names containing certain characters do not parse as a regex
Date Thu, 21 Jun 2012 14:38:43 GMT

     [ https://issues.apache.org/jira/browse/CXF-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Owen Cliffe updated CXF-4391:
-----------------------------

    Description: 
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.  




  was:
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   

    
> 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.  

--
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

        

Mime
View raw message