Description of problem: OASIS is now redirecting HTTP requests for their WSRP WSDL to HTTPS with an HTTP 302 response that includes an XML document that has a public ID but no system ID. This causes the following exception when JBossWS tries to parse the WSDL: Caused by: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId. at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at org.jboss.ws.tools.wsdl.JBossWSDLReaderImpl.getDocument(JBossWSDLReaderImpl.java:2128) ...many more stack frames Steps to reproduce: - Log in as root - Navigate to Group / WSRP - Create a consumer named: netunity - Click "Create Consumer" button - Producer WSDL URL: http://wsrp.netunitysoftware.com/WSRPTestService/WSRPTestService.asmx?Operation=WSDL - Click "Refresh & Save" button Actual results: Exception above Expected results: Successful add
Created attachment 591312 [details] wsrp-entity-fix.zip Attached is a potential fix/workaround. To install: cd $JBOSS_HOME/server/$PROFILE/conf unzip /path/to/wsrp-entity-fix.zip This will make the JBossWS entity resolver use the WSDLs and XSDs placed in the unzipped folder instead of the ones from the OASIS website. I did have to slightly modify the catalog entries already in the file, and I don't know for sure if it affects the function of other JBossWS components; I haven't run the full test suite with the new catalog installed. I would be surprised if there were issues with the change, though. I tried to implement a code change in JBossWSEntityResolver to enable the ability to put an entities file in a deployment, but I haven't been successful so far. I've only done initial work on this, though, since this may not be needed in this situation. If the provided workaround using wsrp-entity-fix.zip is considered sufficient, then this code change won't be needed.
If it works for our customer, that's good for now. However, we should also probably include the WSRP v2 WSDL files. More importantly, though, moving forward, we need a JBoss WS supported way to add such mappings without requiring to modify the AS installation.
Even though JBWS-3165 would be a great fix for this issue, it is not a trivial task to complete. I believe JBPAPP-9337 is sufficient and rather simple to implement. I have not tested a fix for JBPAPP-9337, so I can't say 100% that it is simple; I'm basing this upon my code analysis and how I think it should work.
Kyle, Why is the standard XML XSD resolved from the wsdl director? Also, there's a jax-ws-catalog.xml file in $JBOSS_HOME/server/$PROFILE/conf which contains mappings from Public/System Ids to local files, couldn't we piggy back on this file instead of adding a new file? I tried adding references to the WSRP files there but it didn't work so maybe this why EAP doesn't support catalog files properly? I would also argue that the directory that contains the WSRP-specific schemas should be named differently (probably wsrp). Finally, if the current solution is the only one that would work with minimal effort at this time (i.e. targeting EAP 5.1.2), could you also do the same changes so that the WSRP 2 schemas are also resolved locally, please?
> Why is the standard XML XSD resolved from the wsdl director? This can be changed easily. Changing the dir name to 'wsrp' should be fine. > What about conf/jax-ws-catalog.xml? I'm not sure why this file is there for you, but it's only used by CXF. JBossWS Native doesn't have any code to parse jax-ws-catalog.xml and add the information to the deployment metadata. Adding this code would be a major change to code, and this is why I am opting for the simpler (code-change-wise) solution. I see that file is in EPP 5.2.1, but I'm not sure why. JBossWS Native doesn't use it (confirmed by Jim Ma). > Can you add WSRP 2 schemas? Sure, I can do this. Would you mind to give me the information needed to add these and test them?
For the WSRP v2 files, please follow the same procedure as above using http://www.netunitysoftware.com/wsrp2interop/WsrpProducer.asmx?Operation=WSDL&WsrpVersion=Two as the WSDL URL instead. All files should be resolved locally afterwards. Please do change the name of the directory to wsrp as well to avoid any confusion as to what its content is. Thanks a lot!
Kyle, Did you get a chance to add the WSRP 2 files?
Jim Ma <ema> made a comment on jira JBPAPP-9337 Hi Kyle, I've added the ability to resolve the jbossws-entities.properties under WEB-INF/classes , and committed the fix to jbossws-native-3.1.2 branch. Can you please help try if that works in WSRP2 ? Thanks.
As it stands Kyle's patch could be applied as-is. This would require altering the GateIn/EPP packaging as it modifies the underlying AS. However, I would like this patch extended to also include the WSRP 2 schemas and change the schema directory name from "wsdl" (which is too generic) to "wsrp" (as that directory only contains WSRP-related schemas.
I changed directory from wsdl to wsrp, and edited jbossws-entities.properties file.
Verified, both netunity v1 & v2 now works as expected.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: OASIS is now redirecting HTTP requests for their WSRP WSDL to HTTPS with an HTTP 302 response that includes an XML document that has a public ID but no system ID. Consequences: Ghrows exception SAXParseException: White spaces are required between publicId and systemId. Fix: JBossWS entity resolver use the WSDLs and XSDs placed in the unzipped folder instead of the ones from the OASIS website. Result: Verified, both netunity v1 & v2 now works as expected.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1,3 @@ -Cause: OASIS is now redirecting HTTP requests for their WSRP WSDL to HTTPS with an HTTP 302 response that includes an XML document that has a public ID but no system ID. +OASIS changed the way HTTP WSRP WSDL requests were redirected. The requests redirected to a HTTP 302 response that included an XML document with a public ID, but no system ID. This caused an exception "SAXParseException: White spaces are required between publicId and systemId" to be raised. -Consequences: Ghrows exception SAXParseException: White spaces are required between publicId and systemId. +The fix introduces changes to the JBossWS entity resolver, which now uses the WSDLs and XSDs placed in the unzipped folder instead of the ones from the OASIS website. -Fix: JBossWS entity resolver use the WSDLs and XSDs placed in the unzipped folder instead of the ones from the OASIS website. +This corrects the issue, and restores expected functionality to Netunity v1 & v2.-Result: Verified, both netunity v1 & v2 now works as expected.
Verified again at 5.2.2 CR01