Hi, Eran..., a servlet can be accessed via both http:// and https://.
So, the new method should support the generation of https:// based EPR as well, shouldn't it?
Regards,
Derek Ho ( [EMAIL PROTECTED] )
IBM Web Services Development
| "David Illsley"
<[EMAIL PROTECTED]>
09/12/2006 08:35 AM
|
|
I'm still not fond of this because I can't see how it can be easily
used, and it complicates the interface with no explanation to an
implementor of what it's valid to return.
Please consider writing some Javadoc which explains what the
implementor may return and what a consumer of the array should expect
in terms of ability (or lack thereof) to use any element in the array.
David
On 12/09/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
> David Illsley wrote:
> > On 12/09/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
> >> David Illsley wrote:
>
> >> I will not update but rather deprecate it. This is especially useful
> >> when a service lists out EPRs. Determining which EPR to use will be
> >> transport dependent code. For example, one might getEPRs using this
> >> method and generate proper binding within WSDL.
> >
> > ok, so if you deprecate that method presumably you'll remove it's use
> > in ServiceContext and OutInAxisOperationClient? How will they
> > determine which element in the array to use?
>
> If a listener returns more than one EPR, any EPR is valid. So pick one.
> I'd say the first one.
>
> What that means is, if there is a servlet which returns following EPRs :
>
> http://myip/myhome/services and
> http://myip/anotherHome/services
>
> then it should be able to handle any of them.
>
> But we might want to special case REST EPRs. That's a different issue.
>
>
>
> -- Chinthaka
>
>
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
