Hide Forgot
This is a placeholder for JBoss WS issue JBWS-3511 It's not possible to test with Netunity public producer (v1) due to this issue. Steps to Reproduce: 1. Log in as root in EPP 5.2.1 2. Navigate to Group / WSRP 3. Create a consumer named: netunity 4. Click "Create Consumer" button 5. Producer WSDL URL: http://wsrp.netunitysoftware.com/WSRPTestService/WSRPTestService.asmx?Operation=WSDL 6. Click "Refresh & Save" button Actual results: Unable to register netunity producer
Alessio Soldano <asoldano> made a comment on jira JBWS-3511 Also see [1] , this looks to me a duplicate of the issue already raised there. There's actually not a lot to do here to solve the problem, the issue is in the OASIS 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. Correct schema resolution is not possible in that case. As suggested / discussed in [1] and [2], the "solution" here is leveraging catalogs to avoid the need for going to the internet to resolve the WSRP wsdl & schemas. Depending on the jbossws stack in use (native or cxf based), that is done using either as explained in [2] (native stack) or using jax-ws-catalog.xml catalogs (cxf stack). Attached is an example of jaxws catalog that can be used to read the schemas/wsdl from the file system (but you can also use "classpath:/" to read from jars in the classpath). I've been successfully testing that using the zip wsrp-entity-fix.zip attached to [1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=831445 [2] https://issues.jboss.org/browse/JBPAPP-9337 [3]
Alessio Soldano <asoldano> made a comment on jira JBWS-3511 Also see [1] , this looks to me a duplicate of the issue already raised there. There's actually not a lot to do here to solve the problem, the issue is in the OASIS 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. Correct schema resolution is not possible in that case. As suggested / discussed in [1] and [2], the "solution" here is leveraging catalogs to avoid the need for going to the internet to resolve the WSRP wsdl & schemas. Depending on the jbossws stack in use (native or cxf based), that is done using either as explained in [2] (native stack) or using jax-ws-catalog.xml catalogs (cxf stack). Attached is an example of jaxws catalog that can be used to read the schemas/wsdl from the file system (but you can also use "classpath:/" to read from jars in the classpath). I've been successfully testing that using the zip wsrp-entity-fix.zip attached to [1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=831445 [2] https://issues.jboss.org/browse/JBPAPP-9337
Alessio Soldano <asoldano> updated the status of jira JBWS-3511 to Resolved
Alessio Soldano <asoldano> updated the status of jira JBWS-3511 to Closed