Dan Diephouse wrote:
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?
I have thought about this, and have implemented http/s such that it can
handle that. It just can't handle "protocol" switches. The requirement
from the Client is that the "conduit" is the abstraction that is
delivering the message and the client can place constraints on that.
It's the way in which you talk to the endpoint. We just allow for
address overrides. The advent of TrustDecider callbacks alleviate any
concerns the application may have about the ENDPOINT_ADDRESS override,
or redirects.
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?
That of course, begs the question "What is a transport?" I don't think
we have sufficiently defined that term.
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.
Right. Currently, I keep address overrides with in the HTTP conduit.
Note that this is only specific to the HTTPConduit implementation, and
not in general.
Cheers,
-Polar
- Dan
