cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <>
Subject Re: [PROPOSAL] Pluggable Conduit Initiation Strategy
Date Mon, 02 Apr 2007 17:54:39 GMT
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).

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.

Otherwise, the client has no hope in getting any of its requirements 
satisfied by the
underlying architecture.


Andrea Smyth wrote:
>> Are we not happy with our ability to select a different Conduit 
>> inside the
>> MessageSenderInterceptor? I don't see how this could be an issue. 
>> Just set a
>> new Conduit on the Exchange in a previous interceptor.
> Hi Dan,
> Maybe I am missing something here - but doesn't the fact that any 
> interceptor run before the MessageSenderInterceptor can set the 
> conduit prove that the client - conduit coupling is very loose indeed?
> In the presence of such an interceptor, it makes perfect sense to me 
> to not initialise a conduit upfront if it's possible/certain that this 
> is never going to be used.
> In that case I don't understand your objections aginst the proposed 
> strategy pattern.
> Cheers,
> Andrea.

View raw message