cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: [PROPOSAL] Pluggable Conduit Initiation Strategy
Date Mon, 02 Apr 2007 18:13:52 GMT
On 4/2/07, Polar Humenn <phumenn@iona.com> 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
http://envoisolutions.com | http://netzooid.com/blog

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