On 4/2/07, Polar Humenn <[EMAIL PROTECTED]> 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
