search

javaee / metro-wsit

https://javaee.github.io/metro-wsit/
Other
9 stars 24 forks source link

Wsimport throws HTTP 500 for MEX endpoint #515

Closed glassfishrobot closed 14 years ago

glassfishrobot commented 17 years ago

When invoking wsimport on the following MEX URL, it throws HTTP 500.

http://java11.india.sun.com/MTOM_Service_Indigo/Soap11MtomUtf8.svc/mex

The exception stacktrace is below. ======================snip====================== D:\wkspc\mex\tmp>....\forrunning\glassfish\bin\wsimport.bat -Xdebug http://java11.india.sun.com/MTOM_Service_Indigo/Soap11MtomUtf8.svc/mex parsing WSDL...

java.io.IOException: Server returned HTTP response code: 500 for URL: http://java11.india.sun.com/MTOM_Service_Indigo/Soap11MtomUtf8.svc/mex at com.sun.tools.ws.wscompile.ErrorReceiver.error(ErrorReceiver.java:73) at com.sun.tools.ws.wsdl.parser.DOMForest.parse(DOMForest.java:215) at com.sun.tools.ws.wsdl.parser.DOMForest.parse(DOMForest.java:134) at com.sun.tools.ws.wsdl.parser.MetadataFinder.parseWSDL(MetadataFinder.java:81) at com.sun.tools.ws.wsdl.parser.WSDLParser.parse(WSDLParser.java:128) at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:112) at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.tools.ws.Invoker.invoke(Invoker.java:100) at com.sun.tools.ws.WsImport.main(WsImport.java:38) Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: http://java11.india.sun.com/MTOM_Service_Indigo/Soap11MtomUtf8.svc/mex at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1174) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973) at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:184) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:798) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) at com.sun.tools.ws.wsdl.parser.DOMForest.parse(DOMForest.java:197) ... 11 more [ERROR] Failed to read the WSDL document: http://java11.india.sun.com/MTOM_Service_Indigo/Soap11MtomUtf8.svc/mex, because 1)could not find the document; /2) the document could not be read; 3) the root element of the document is not . unknown location

Failed to parse the WSDL. ======================snip======================

However, its interesting to note the same URL works fine and generates artifacts for svcutil.exe

Its a blocker for MTOM/WSA interop tests using MEX & must be fixed.

Environment

Operating System: All Platform: All

Affected Versions

[current]

glassfishrobot commented 17 years ago

Reported by vrdeepak@java.net

glassfishrobot commented 17 years ago

karthikeyan_k@java.net said: This same also happens for SecureConversation and Security mex endpoints: http://java11.india.sun.com/IndigoService/WsSecureConversation.svc/mex http://java11.india.sun.com/IndigoService/WsSecurity10.svc/mex

glassfishrobot commented 17 years ago

daveronge@java.net said: Same for jax-rm, nevertheless, the mex endpoints for RM do return some response showing part of wsdl. This looks fine from beginning but I was never able to see a case a whole wsdl document is returned - the body is always broken at some point after the - the wsmonitor says "Unexpected end of file" without further info, but tcpmonitor shows beginning of the response which looks correct but only about one third of the full length is returned. That is blocker for RM interop too.

glassfishrobot commented 17 years ago

daveronge@java.net said: Created an attachment (id=356) Example of partial response of the internal public MEX endpoint for RM from jaxps.india:80

glassfishrobot commented 17 years ago

daveronge@java.net said: All interop machines that can be reached in SWAN - without proxy - and be tcpmonitored behave in the same manner, supposedly there are some issues with reading whole document as svcutil.exe can create the artifacts (according to the above information). The response body part has no eols (one-liner).

glassfishrobot commented 17 years ago

hofsass@java.net said: Analysis:

This happens because WCF endpoint at successfully returns HTML to wsimport first. wsimport determines it's not a WSDL and retries with MEX. MEX tries at the same endpoint which fails (because WSDL is at /mex) then at /mex, which succeeds. This is what you see in the first case of your testmex script.

When 'wsimport' is pointed directly at /mex it fails because the initial attempt via HTTP to get the WSDL at /mex errors. The default WCF MEX endpoint behavior does not provide any HTTP/HTML at /mex. For HTTP GET request it just gives 500 HTTP error return. Then 'wsimport' blows up with an IoException in DOMForest.parse() at line 197 [reader.parse(inputSource)] which ends the whole process. So, 'wsimport' never even tries with MEX in this scenario.

glassfishrobot commented 17 years ago

vivekp@java.net said: Fixed in JAX-WS, hudson build#22

glassfishrobot commented 17 years ago

vivekp@java.net said: corrected target milestone.

glassfishrobot commented 17 years ago

daveronge@java.net said: Works with RM

glassfishrobot commented 17 years ago

File: mex.response.xml Attached By: daveronge@java.net

glassfishrobot commented 17 years ago

Was assigned to vivekp@java.net

glassfishrobot commented 7 years ago

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

glassfishrobot commented 14 years ago

Marked as fixed on Monday, February 15th 2010, 12:39:28 am