[jira] [Comment Edited] (CXF-4811) Allow conduit match pattern to be customized.

["Jason Pell (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578150#comment-13578150 ] 

Jason Pell edited comment on CXF-4811 at 2/14/13 4:46 AM:
----------------------------------------------------------

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.

https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/server/conduit/HttpConduitConfigurerImpl.java

This code does require Spring 3 for the Environment stuff.

You register this configurer in spring:

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

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:

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

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

{code}
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", properties));
        
        context.refresh();
        
        return context;
    }
{code} 

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


                
      was (Author: pellcorp):
    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.

https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/server/conduit/HttpConduitConfigurerImpl.java

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", properties));
        
        context.refresh();
        
        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: 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