cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: [PROPOSAL] Pluggable Conduit Initiation Strategy
Date Mon, 02 Apr 2007 18:13:52 GMT
On 4/2/07, Polar Humenn <> wrote:
> You are right, but this situation should be sured up some more.
> One of two approaches should be selected. Either:
> 1. The Client selects/configures the Conduit according to its
> requirements, and it
>    *cannot* be changed. (i.e. no calls to "setConduit" should exist
> anywhere in the
>    public API).

This isn't feasible unless we select detect the new endpoint address inside
the Conduit itself. Which I thought we decided was less than ideal?

2. The Client sets a Conduit selection/configuration policy that *cannot* be
>     changed, and interceptors can only get a conduit from Conduit factory
>     that adheres to that policy.

Could the overridden endpoint address be a completely different transport?
Then there isn't really feasible way to handle this as there isn't a way to
copy Conduit configurations. For instance, my HTTP configuration for trust
doesn't really translate well to a JMS configuraiton.

- Dan

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message