cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] [Resolved] (CXF-5320) HTTP Conduits allow for little flexibility when matching against URLs
Date Thu, 03 Oct 2013 14:27:42 GMT


Daniel Kulp resolved CXF-5320.

       Resolution: Duplicate
    Fix Version/s: Invalid

Duplicate of CXF-4811

Patch welcome.

> HTTP Conduits allow for little flexibility when matching against URLs
> ---------------------------------------------------------------------
>                 Key: CXF-5320
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.6.10, 2.7.7
>            Reporter: Raul Kripalani
>             Fix For: Invalid
> The current architecture to configure HTTP Conduits in Spring doesn't allow for enough
flexibility when matching against endpoint URLs.
> URLs can change between one environment and the other, not just the host and port, but
also the context. Most developers don't have a guarantee of what URLs will look like in upper
environments, now or in the future.
> Ideally the matching regex would be parameterized, but this is impossible because the
pattern goes in the bean name, and Spring won't resolve placeholders for bean names!
> Something like this is not possible:
> {code}
>     <http:conduit name="${service.url}">
>         <http:client ConnectionTimeout="${service.timeouts.connect}" 
>                           ReceiveTimeout="${service.timeouts.receive}"/>
>     </http:conduit>
> {code}
> A way to achieve this this level of parameterization is to use the HTTPTransportActivator
Managed Service Factory. But this mechanism is only available in OSGi containers.
> I propose adding an 'url' attribute to the http conduit XML element, so that the pattern
can be resolved from a property file.

This message was sent by Atlassian JIRA

View raw message