[
https://issues.apache.org/jira/browse/CXF-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578136#comment-13578136
]
Jason Pell commented on CXF-4811:
---------------------------------
I am experimenting with registering a custom HTTPConduitConfigurer as a cxf
extension. In spring 3 I can get access
to the Environment and use the resolvePlaceholders to expand the properties and
then use the regex as for ConfigurerImpl.
If you look at the HTTPTransportFactory it looks for a HTTPConduitConfigurer
before it calls the Configurer.
> Allow conduit match pattern to be customized.
> ---------------------------------------------
>
> Key: CXF-4811
> URL: https://issues.apache.org/jira/browse/CXF-4811
> Project: CXF
> Issue Type: New Feature
> Components: Integration
> Affects Versions: 2.4.3
> Reporter: Ivan Latysh
> Priority: Critical
>
> Use-case:
> Developed jaxrs client has no knowledge of the server URL until it is
> shipped to a customer.
> To address the issue, server name and port has been externalized and
> handled by a standard {{PropertyPlaceholderConfigurer}}:
> {code}
> <jaxrs:client id="serviceClient"
> address="http://${server.name}:${server.port}/services/*"/>
> <context:property-placeholder/>
> <bean
> class="org.springframework.web.context.support.ServletContextPropertyPlaceholderConfigurer">
> <property name="order" value="1"/>
> <property name="ignoreUnresolvablePlaceholders" value="false"/>
> </bean>
> {code}
> But currently http conduit can not be configured as match pattern is set the
> conduit name, rather than a property.
> {code}
> <cxf-http:conduit name="http://localhost/services.*"; />
> {code}
> The best option is to introduce custom URL Matchers, so conduit delegate
> actual URL matching to a configurable implementation.
> Than a simple solution would be to extend
> org.apache.cxf.configuration.spring.ConfigurerImpl and resolve the property
> placeholders before compiling the pattern in {{initWildcardDefinitionMap}}
> method. But the poor architectural decisions led to
> {{PropertyResourceConfigurer}} to be non-reusable. It supports rigid visitor
> pattern, and do not even provide a method to resolve a property placeholder
> after {{postProcessBeanFactory}} has been called.
> So the dirty hack would be to configure pattern in the conduit property,
> rather in the name.
> {code}
> <cxf-http:conduit id="service1Conduit">
> <property name="url"
> value="http://${server.name}:${server.port}/services/*";>
> </cxf-http:conduit>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
