Re: [PATCH] Service.createDispatch(QName, *) doesn't know about the ports available

From: <>
Date: Thu, 22 Sep 2005 10:38:17 +0100

On 1 Sep 2005, at 11:27, wrote:
> I've been trying to use the createDispatch(QName, ...) method for a
> service I've created from a WSDL. Unfortunately the WebService
> implementation does not use the WSDL information to know about the
> available ports and their binding detals so it throws an exception
> if I try to create a Dispatcher for a known port.
> The work around is to explicitly call addPort() first before using
> it - but given that the WebService has parsed the WSDL and knows
> what all the ports are it seems silly to force the user to add all
> the ports that WebService already knows about right?
> I'm assuming this is just an oversight/bug and that I'm the first
> to hit this - please forgive me if I've misunderstood. As an
> experiment I thought I'd try patch WebService to actually find the
> available ports from the WSDL and use those by default which seems
> much nicer and less surprising from an end users perspective. It
> turns out it was very simple to do - I just added this new method
> to the WebService class....


My patch never made it into CVS :(.

Though things have moved about quite a bit since then. So I've
recreated my patch again using the latest CVS HEAD...

If its easier I've attached the full modified version of the file...

Its a pretty trivial patch; if you try to dispatch to a dispatchPort
that's not been added/used before it double checks in the WSDL
context to see if its a known port and adds it for you - since it
knows all of the information required to add the port.

I'm assuming this is still a valid approach right? It seems silly for
the Service to parse the WSDL & know the bindingId and
endpointAddress of all the ports - then for a user to be able to
dispatch to a port, they have to re-parse the WSDL themselves to find
the bindingID and endpointAddress to then call addPort() so that the
createDispatch() method will actually work.

If so I'm quietly hopeful it can be committed soon so I don't have to
depend on a patched version of JAX-WS RI :)