Okay Dan,
I was under the impression that the Conduit was tied to a particular
"endpoint", which in my mind was specified as a host:port+path
designation. I am undoubtedly mistaken on this point. I think I'm just
confused as to the formal definition of Endpoint, whatever that may be.
A Conduit is merely a message sender to a *type* of service, no matter
where that service may be?
Please bear with me as I try to figure out the invariants.
What are the formal requirements for ConduitInitiatorManager and
ConduitInitiator?
The ConduitIntiatorManager looks like it supposed to get a
ConuitInitiator via a
particular namespace, which I assume is something of the form:
"http://apache.org/hello_world_soap";
and is merely an identifier with no "server like" hosts that are implied
targets for my requests. Is this correct? These appears to be organized
as "activationNamespaces". What are "activation" namespaces?
I assume from this, that the ConduitInitator returned from the
CoduitInitiatorManager is only supposed to issue Conduits in the
namespaces it has been registered under? That could be one to many, as
one conduit initiator may be registered for many namespaces.
From the ClientImpl the namespace seems to be the "TransportID" from
the EndpointInfo. What is the "TransportId" supposed to mean? Is this an
"activation" namespace? What is the correlation?
Then the Conduit is gotten from ConduitInitiator based on the
EndpointInfo object and possibly a corresponding EndpointReferenceType
object (what's the formal correlation of these two?). On what basis is
that Conduit supposed to be created or selected?
It seems that currently in CXF there is *only* one ConduitInitiator for
all of "http" and that's the http(2).HTTPTransportFactory. It is
registered under any number of "activation" namespaces, which seems to
be governed by some configuration device.
This implemenation generates a *new* conduit for each
getConduit(EndpointInfo, EndpointReferenceType) call and there is no
reuse of conduits. The ClientImpl asks for a conduit for each message it
creates to a particular endpoint. So the point seems to be moot, as the
Endpoint stuff only provides a *default* should the application not want
to "override" with the ENDPOINT_ADDRESS, PATH_INFO, and QUERY_STRING.
So, basically, we can make no assumptions about a Conduit as a point of
protection or trust.
Operationally, as Eoghan pointed out, we really cannot even assume the
actual protocol it is going to handle. Is this correct summation?
Cheers,
-Polar
Dan Diephouse wrote:
I don't know that there is a formal requirement that a Conduit be
attached
to a single host or attached to a host+path.
I also think you're exaggerating the problem of overriding the endpoint
address. Typically people will want to use a different address for a
development server instead of production. So their configuration is
likely
to apply to both. I don't really see any users just sticking in a random
address there and having an issue with trusting a rogue server.
If you have suggestions about how this should work, would love to hear
them.
On 3/13/07, Polar Humenn <[EMAIL PROTECTED]> wrote:
Aside from this being just plain wrong, there might be a requirement
that the endpoint that the conduit is created with is just a URL with
host information.
Is it supposed to be the case that the EndpointInfo.getAddress() or
EndpointReferenceType.getAddress() is only a URL of the form
"http://host.com:1234"; or is there an associated path?
In what situations is the PATH_INFO used? Is it part of the JAX-WS?
Cheers,
-Polar
Dan Diephouse wrote:
> On 3/12/07, Polar Humenn <[EMAIL PROTECTED]> wrote:
>
>> Shouldn't this conduit ONLY be sending messages to the endpoint
>> designated (configured) for it?
>>
>> Furthermore, the code fragment in setupURL
>>
>> String result = value != null ? value : url.toString();
>> if (null != pathInfo && !result.endWith(pathInfo)) {
>> result = result + pathInfo;
>> }
>>
>> has a bit of a caveat in that you'd never be able to send a
request to
a
>> location
>> of "http://somewhere.com/xx/xx";, specified by a URL of
>> "http://somwhere.com/xx"; a Message.PATH_INFO property of "/xx".
>>
>> Now some might say "why would you want to do that?" I know "xx"
doesn't
>> make sense to most, but what about,
>>
>> "http://somewhere.com/path/to/parent/..";
>>
>> as a URL location built up from other things you might have dealt
with,
>> and you want to set a path from there to be "/.." Then you are in a
>> completely different location than you want to be.
>>
>> Is there a specific "contract" are placed on
Message.ENDPOINT_ADDRESS,
>> Message.PATH_INFO for this situation, or its it a bug?
>
>
> -1 to changing this. PATH_INFO is supposed to be all the stuff
after the
> host. Just like URI.getPath(). -
> http://java.sun.com/j2se/1.5.0/docs/api/index.html?java/net/URI.html
>
> - Dan
>
>
