cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: http: URLs and setepURL
Date Tue, 13 Mar 2007 01:58:22 GMT
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 <eoghan.glynn@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Polar Humenn [mailto:phumenn@iona.com]
> > Sent: 12 March 2007 20:28
> > To: cxf-dev@incubator.apache.org
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message