Multiple wsdls bundled in one war file cause run time mex fail.

[glassfishrobot]

If more than one services bundled in one war file, then the runtime MEX call wiil get all the WSDLs returned and only one of them is processed. This caused failure for JAVAONE demo where the following is throwed for dispatch client with run time mex address of the STS:

Caused by: javax.xml.ws.WebServiceException:

{http://tempuri.org/}

SecurityTokenService is not a valid service. Valid ser vices are:

{http://example.org/wholesaler}

WholesaleService

This is because the service wsdl is returned by mex run time instead the sts wsdl.

Environment

Operating System: All Platform: All

Affected Versions

[current]

[glassfishrobot]

Reported by jdg6688@java.net

[glassfishrobot]

vivekp@java.net said: Assigning to Jitu.

[glassfishrobot]

bbissett@java.net said: I'm just curious about the issue. It sounds like mex is doing what it's supposed to at the basic level – there's no way in a mex Get call to specify the information you'd like returned. So an endpoint should return all its metadata when responding to the request.

Is the root issue that the request is going to an endpoint address instead of an sts address, or is it that the endpoint is returning both an endpoint wsdl and an sts wsdl (if that question makes sense)? I can't tell exactly from the output, but it looks in essence like the dispatch object was created with one endpoint (wholesale service) and then is seeing another one (sts) when the call is made.

[glassfishrobot]

jdg6688@java.net said: The dispatch call is to the STS endpoint. Both the wsdls for the service and the sts are returned in the response and the wsdl for the service is picked.

[glassfishrobot]

jitu@java.net said: If a war file contains multiple WSDL/XSDs, a mex request for endpoint1 could also include WSDL/XSD for endpoint2. This is fixed by finding the transitive closure of the documents for each endpoint. WSEndpoint.getServiceDefinition() will give only that endpoint's documents. This means some customization files may require to be changed since previously the mapping is based on the entire war. This is not a big change(for e.g ?xsd=3 to ?xsd=2)

[glassfishrobot]

jitu@java.net said: EndpointFactory, SDDocumentImpl is changed to find a set of documents required for Endpoint.

[glassfishrobot]

jdg6688@java.net said: Verified

[glassfishrobot]

mmatula@java.net said: This issue was fixed before we created 1.0 branch, so the fix is in 1.0 -> setting target milestone to say so.

[glassfishrobot]

Was assigned to jitu@java.net

[glassfishrobot]

This issue was imported from java.net JIRA WSIT-232

[glassfishrobot]

Marked as fixed on Tuesday, November 13th 2007, 11:46:28 pm