Return-Path: 
 <issues-return-24358-apmail-cxf-issues-archive=cxf.apache.org@cxf.apache.org>
X-Original-To: apmail-cxf-issues-archive@www.apache.org
Delivered-To: apmail-cxf-issues-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 05448D5D5
	for <apmail-cxf-issues-archive@www.apache.org>;
 Thu, 14 Feb 2013 04:46:27 +0000 (UTC)
Received: (qmail 61049 invoked by uid 500); 14 Feb 2013 04:46:24 -0000
Delivered-To: apmail-cxf-issues-archive@cxf.apache.org
Received: (qmail 60887 invoked by uid 500); 14 Feb 2013 04:46:22 -0000
Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cxf.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cxf.apache.org>
List-Post: <mailto:issues@cxf.apache.org>
List-Id: <issues.cxf.apache.org>
Reply-To: dev@cxf.apache.org
Delivered-To: mailing list issues@cxf.apache.org
Received: (qmail 60662 invoked by uid 99); 14 Feb 2013 04:46:15 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Feb 2013 04:46:15 +0000
Date: Thu, 14 Feb 2013 04:46:15 +0000 (UTC)
From: "Jason Pell (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12630911.1360084735362.287672.1360817175689@arcas>
In-Reply-To: <JIRA.12630911.1360084735362@arcas>
References: <JIRA.12630911.1360084735362@arcas>
Subject: [jira] [Commented] (CXF-4811) Allow conduit match pattern to be
 customized.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


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

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.

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