[
https://issues.apache.org/jira/browse/CXF-5320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raul Kripalani updated CXF-5320:
--------------------------------
Summary: HTTP Conduits allow for little flexibility when matching against
URLs (was: HTTP Conduits allow for little flexibility when matching URLs)
> HTTP Conduits allow for little flexibility when matching against URLs
> ---------------------------------------------------------------------
>
> Key: CXF-5320
> URL: https://issues.apache.org/jira/browse/CXF-5320
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.6.10, 2.7.7
> Reporter: Raul Kripalani
>
> 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
(v6.1#6144)
