I tend to agree with Polar that it is kind of weird. I thought the idea was that a Conduit is supposed to be a Conduit to a particular endpoint, not many.
BUT there is the practical issue of configuration. We may want to configure our conduit based on: 1. The particular jax-ws client & the wsdl port it is talking to 2. The particular URL 3. Both 1 & 2. The problem with #1 is that you have to put in the logic in conduits that we already have. The problem with #2 is that we can't have different clients talk to the same url with different settings. I guess we could go down the route of: - If a different EPR is specified create a new Conduit in the MessageSenderInterceptor - Apply the configuration to the new conduit like it would be applied to the original conduit But wouldn't that be pretty much equivalent (at least for the HTTP case)? - Dan On 3/12/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> -----Original Message----- > From: Polar Humenn [mailto:[EMAIL PROTECTED] > Sent: 12 March 2007 20:28 > To: [email protected] > Subject: http: URLs and setepURL > > In the HttpConduit I have noticed that the "url" for the > conduit is set up in the constructors from the EndpointInfo, > or the EndpointReferenceType. > > However, it maybe totally overridden in send(Message) by the > Message.ENDPOINT_ADDRESS on the message. What purpose does this have? I'd imagine the purpose is to support the standard JAX-WS mechanism whereby the application can explicitly control the target address by setting the BindingProvider.ENDPOINT_ADDRESS_PROPERTY on the request context. > Shouldn't this conduit ONLY be sending messages to the > endpoint designated (configured) for it? Not necessarily. The purpose of the BindingProvider.ENDPOINT_ADDRESS_PROPERTY is to give the client application the flexibility to override the target endpoint address if necessary. For example the service may have migrated to a new address, but the WSDL or annotated Java available to the client app may be out-of-date. > 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". If you think this is an important usage scenario, feel free to submit a patch with a fix. > 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? > > Cheers, > -Polar > >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
