Doug Kohlert wrote:
>
>
> Kohsuke Kawaguchi wrote:
>
>> Doug Kohlert wrote:
>>
>>> Atcually,
>>> This method is not only used to check what the proxy/dispatch is
>>> talking to. It can be used as an EPR factory for any endpoint,
>>> especially in the dispatch case. You could do the following in
>>> some type of EPR registry application.
>>>
>>> Service service = Service.create(wsdlDoclocation, serviceName);
>>> service.addPort(portName, .SOAPBinding.SOAP11HTTP_BINDING,
>>> endpointAddress);
>>> Dispatch dispatch = service.createDispatch(portName, Source,
>>> Service.Mode.PAYLOAD);
>>> EndpointReference epr = dispatch.getEndpointReference(refParams);
>>
>>
>>
>>
>> If the service and dispatch above are used simply as a way to create
>> an EPR, then that's one semantics. If the getEndpointReference is
>> used as a way to obtain an EPR that the BindingProvider is talking
>> to, that's another semantics.
>>
>> But I don't think you can mix both of them in one method. The case
>> that illustrates where such mix breaks down is what happens if you call:
>>
>> dispatch.getEndpointReference(/*no args*/)
>>
>> If this is a factory "create" method, then this shall return an EPR
>> w/o any reference parameters (regardless of whether this dispatch is
>> sending out reference parameters when its invoke method is called.)
>> If this is a real "get" method, then this shall return an EPR with
>> the exact set of reference parameters that the dispatch is configured
>> to use.
>
>
> Good point. I suppose we should remove the referennce parameters from
> this method.
Actually, upon further reflection, you can still have it work both
ways. The developer just needs to know that the EPR is going to have
the reference parameters already specified on the BindingProvider. So
if they want to use this method as a type of factory to get a clean EPR,
they should not call it on a BindingProvider that was created from an
EPR, which will be the case the majority of the time. Why would a
developer create a BindingProvider from an EPR that has reference
parameters, and then turn around and call getEPR() on that
BindingProvider? If they created the BindingProvider in the JAX-WS 2.0
manner, there will be no reference parameters and no conflict.
>
>>
>> So I think you have to make up your mind as to what this method
>> really is.
>>
>>
>> I thought we've all been saying that such low-level EPR construction
>> is not something we are exposing from the JAX-WS API (a system-level
>> programmer can always do so by building infoset on his own.)
>>
> We have received some use cases that suggest that the application
> developer still needs to create an EPR.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>