cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Pell (JIRA)" <>
Subject [jira] [Commented] (CXF-4811) Allow conduit match pattern to be customized.
Date Thu, 14 Feb 2013 04:46:15 GMT


Jason Pell commented on CXF-4811:

Thanks for the clarification.  for my needs I am not using OSGI, so not an issue.  So I have
a first stab at such a configurer based on some of the code from ConfigureImpl.

This code does require Spring 3 for the Environment stuff.

You register this configurer in spring:

	<bean id="com.pellcorp.server.conduit.HttpConduitConfigurer"
class="com.pellcorp.server.conduit.HttpConduitConfigurerImpl" />

I could have added a META-INF/cxf/bus-extensions.txt and added a setBus method and then got
hold of the ApplicationContext via the
bus getExtensions method, but in my mind just dropping it into the context is simpler.

So this allows you to provide a conduit that looks like:

<http:conduit name="https://localhost:${port}/.*">

You can configure your environment before you start your context something like so:

private ClassPathXmlApplicationContext getContext(String path) {
        Map<String, Object> properties = new HashMap<String, Object>();
        properties.put("port", "10000");
        ClassPathXmlApplicationContext context = 
            new ClassPathXmlApplicationContext(new String[] { path }, false);
        context.getEnvironment().getPropertySources().addFirst(new MapPropertySource("env",
        return context;

I am not sure this belongs in CXF, but it is a workable non OSGI solution.

Dan - is there anywhere in CXF this could go?

> Allow conduit match pattern to be customized.
> ---------------------------------------------
>                 Key: CXF-4811
>                 URL:
>             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
>   To address the issue, server name and port has been externalized and handled by a standard
> {code}
> <jaxrs:client id="serviceClient"
> address="http://${}:${server.port}/services/*"/>
> <context:property-placeholder/>
> <bean class="">
> 		<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
> {code}
> <cxf-http:conduit id="service1Conduit">
>   <property name="url" value="http://${}:${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:

View raw message