Himai Minh wrote:I noticed the WSDL in this page:
The targetname space defined in the client code and the WSDL matches.
Himai Minh wrote:When I read CalculatorClient, the service is created using this targetnamespace :http://abhijitsarkar.name/webservices/jaxws/deploy-desc/
Then, the service adds a new port with targetnamespace : http://deploydesc.jaxws.webservices.abhijitsarkar.name/
So, the dispatch is using this new port to invoke the method.
a sarkar wrote:I noticed that a dispatch client works even if the port QName is wrong. This doesn't make sense. Here's a client that shows the aforementioned behavior:
Himai Minh wrote:So, addport means to add a port that never exist in the corresponding WSDL?
That also means no matter the QName of the port is wrong or right, the dispatch client can still connect to the service as long as the endpoint address of the service is correct?
Frits Walraven wrote:However, when you use the getPort(...) method the portName has to match the portName published in the WSDL.
Himai Minh wrote:The service won't know what request JAXBElement the client sends as the WSDL is not used.
a sarkar wrote:The getPort methods require an SEI, which suggests to me that it is intended to be used with the dynamic proxy clients.
a sarkar wrote:For dispatch clients, there is no client side SEI, so addPort may be the only option.
Frits Walraven wrote:
a sarkar wrote:
The portName in the code above, is it verified against the WSDL as in getPort or just about anything like addPort?
a sarkar wrote:
Also, addPort is the only method that accepts a binding type, so without that, it might fallback to the default binding?
I didn't do it. You can't prove it. Nobody saw me. The sheep are lying! This tiny ad is my witness!
Devious Experiments for a Truly Passive Greenhouse!https://www.kickstarter.com/projects/paulwheaton/greenhouse-1