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.
Cheers,
-Polar
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.
