On 12/09/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
David Illsley wrote:
> Eran,
> Can you explain to me how the user of this method will be able to tell
> the difference between e.g. a SOAP and a REST EPR?
Basically, the current behavior is you just ask the EPR from a listener.
Think of this scenario as well. One can map the same servlet to
different context paths. In that case servlet as the http transport
listener can handle more than one EPRs. The current method doesn't
facilitate it.
I understand that there are reasons that you might want multiple EPRs
for an endpoint. The issue I have is that this generic transport api
is providing information which you need specific transport knowledge
to understand.
I've seen code like this before and there is the tendency for people
to just use the first element in the array because they don't know how
to differentiate and that's been a source of problems for me in the
past.
>
> I'm a little nervous about making a change like this without fully
> understanding what and how the multiple EPRs can be used as if it's
> not totally clear it's a probable source of problems.
>
> Also, are you intending to update the ListenerManager.getEPRforService
> method as well? If so, how will its users determine which EPR to use?
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?
David
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
