Bug 779208 - (SOA-1601) WSDL import does not work for Web Service Proxy
WSDL import does not work for Web Service Proxy
Status: CLOSED NEXTRELEASE
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB (Show other bugs)
5.0.0 ER3
Unspecified Unspecified
high Severity high
: ---
: 5.0.0 GA,5.0.0 ER8
Assigned To: Kevin Conner
http://jira.jboss.org/jira/browse/SOA...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-16 03:57 EST by Jiri Pechanec
Modified: 2010-02-12 05:14 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-12 05:14:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
contract_publisher_soapprocessor_import.tar.bz2 (500.02 KB, application/x-bzip2)
2009-12-20 13:30 EST, Boris Belovic
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SOA-1601 Major Closed WSDL import does not work for Web Service Proxy 2012-09-06 11:35:38 EDT

  None (edit)
Description Jiri Pechanec 2009-11-16 03:57:40 EST
Date of First Response: 2009-11-16 04:38:20
project_key: SOA

I have created a JBossWS web service that uses custom WSDL with import element in place.

The original web service publishes wsdl with this element
<wsdl:import location="http://dhcp-0-121.brq.redhat.com:8080/Quickstart_webservice_proxy_basic_ws/HelloWorldImportWS?wsdl&resource=HelloWorldWSSchema.xsd" namespace="http://webservice_proxy_basic/helloworldimport"/>

The proxied one publishes this element
<wsdl:import location="HelloWorldWSSchema.xsd?serviceCat=&serviceName=&protocol=" namespace="http://webservice_proxy_basic/helloworldimport">
</wsdl:import>

It seems that WSDLContractPublisher is not fully prepared to work with proxied web services.
Comment 1 Kevin Conner 2009-11-16 04:38:20 EST
Sorry, are you saying that import was supported previously?  To the best of my knowledge import is not supported in the wsdl.
Comment 2 Jiri Pechanec 2009-11-16 05:00:15 EST
It is in the code, the documentation does not say if it is supported or not then I suppose that WSDL spec is supported as whole :-)
Comment 3 Kevin Conner 2009-11-16 05:03:16 EST
What is in the code?
Comment 4 Kevin Conner 2009-11-16 05:07:02 EST
Sorry, just realised that you are referring to the import of schema within the wsdl and this should be supported.
Comment 5 Kevin Conner 2009-11-16 05:09:03 EST
Sorry, bad morning.  The only explicit use-case supporting import of schema is through EBWS and it does not sound as if this is what you are referring to.

Did this work previously?
Comment 6 Kevin Conner 2009-11-16 05:35:15 EST
Okay, digging around shows that the smooks transformation attempts to handle the wsdl:import by appending those attributes to the schema and, presumably, this worked previously.

Do you have a working example from a SOA 4.3 release and a comparison with the proxy version?


Comment 7 Jiri Pechanec 2009-11-16 06:12:43 EST
We have not tested WSDL import for SOAPProcessor endpoints on SOA-P 4.3
Comment 8 trev 2009-12-02 05:52:03 EST
Can this be verified on SOA 4.3
Comment 9 Boris Belovic 2009-12-07 02:28:26 EST
WSDL import for SOAPProcessor is working correctly on SOA-P 4.3 (verified on SOA-P 4.3 CP02).
Comment 10 Kevin Conner 2009-12-07 05:01:51 EST
Still need the example attached, can someone please do this?
Comment 11 Boris Belovic 2009-12-20 13:30:43 EST
Attached test case for SOA-P 4.3.
Comment 12 Boris Belovic 2009-12-20 13:30:43 EST
Attachment: Added: contract_publisher_soapprocessor_import.tar.bz2
Comment 13 Kevin Conner 2010-01-14 04:53:24 EST
Is this issue still present in ER7?
Comment 14 Kevin Conner 2010-01-19 09:46:42 EST
Link: Added: This issue depends JBESB-3134
Comment 15 David Ward 2010-01-19 15:28:40 EST
1) This jira is mis-named.  The quickstart uses the SOAPProcessor, not the SOAPProxy.

2) Because of the decision made to go along with the workaround described in JBESB-2913 / SOA-1552, we only have to worry about HTTP-based contracts in the contract jsp application, not JMS or SOCKET, so ContractPublisherSOAPProcessorImportTest.java included in the attached test case needs to be updated to ONLY execute this line:
    compareWSDLDocuments(ORIGINAL_URL, HTTP_URL, EXPECTED_HTTP_ENDPOINT);
NOT these lines anymore:
    compareWSDLDocuments(ORIGINAL_URL, JMS_URL, EXPECTED_JMS_ENDPOINT);
    compareWSDLDocuments(ORIGINAL_URL, SOCKET_URL, EXPECTED_SOCKET_ENDPOINT);

3) After doing #2, I deployed and tested the attached use case, using the latest available on the JBESB_4_7_CP (cp1) branch, under both these environments:
    - deployed in JBoss AS 4.2.3 + Sun JDK 1.5.0_22
    - deployed in JBoss AS 5.1.0 + Sun JDK 1.6.0_17
In each case, the "ant runtest" application ran successfully, as did browsing to the contract jsp application, clicking on the HTTP contract, then copying/pasting out the import and into the browser window, and retrieving the imported data successfully.

I have thus closed JBESB-3134 as "Cannot Reproduce Bug".  Please re-test this issue once ER8 becomes available.  Thank you.
Comment 16 David Ward 2010-01-20 11:03:49 EST
FYI, I found out more information on this one....

1) Just a note: the attached quickstarts says GoodbyeWorld, not HelloWorld.  Kinda weird.  No matter.  Anyways...

2) The problem on ER7 - where it is still an issue - is that the port number is getting stripped out of the re-written import URL.  See below:

=======================
SOA-P 5 ER7
(with Sun JDK 1.6.0_17)
=======================

JBossWS
-------

Clicking on this link:
http://127.0.0.1:8080/Contract_publisher_soapproducer_import/GoodbyeWorldWS?wsdl

Yields this import URL (good):
http://127.0.0.1:8080/Contract_publisher_soapproducer_import/GoodbyeWorldWS?wsdl&resource=GoodByeSchema.xsd

ESB
---

Clicking on this link:
http://localhost:8080/contract/contract.jsp?serviceCat=ContractPublisherSOAPProducerCategory&serviceName=ContractPublisherSOAPProducerImportService&protocol=http

Yields this import URL (** BAD! - MISSING PORT! **):
http://127.0.0.1/Contract_publisher_soapproducer_import/GoodbyeWorldWS?wsdl&resource=GoodByeSchema.xsd&serviceCat=ContractPublisherSOAPProducerCategory&serviceName=ContractPublisherSOAPProducerImportService&protocol=http" namespace="http://webservice_producer/goodbyeworldimport

==================================================
Latest available on the JBESB_4_7_CP (cp1) branch
(deployed in JBoss AS 5.1.0 with Sun JDK 1.6.0_17)
==================================================

JBossWS
-------

Clicking on this link:
http://127.0.0.1:8080/Contract_publisher_soapproducer_import/GoodbyeWorldWS?wsdl

Yields this import URL (good):
http://127.0.0.1:8080/Contract_publisher_soapproducer_import/GoodbyeWorldWS?wsdl&resource=GoodByeSchema.xsd

ESB
---

Clicking on this link:
http://localhost:8080/contract/contract.jsp?serviceCat=ContractPublisherSOAPProducerCategory&serviceName=ContractPublisherSOAPProducerImportService&protocol=http

Yields this import URL (** GOOD! - PORT IN TACT! **):
http://127.0.0.1:8080/Contract_publisher_soapproducer_import/GoodbyeWorldWS?wsdl&resource=GoodByeSchema.xsd&serviceCat=ContractPublisherSOAPProducerCategory&serviceName=ContractPublisherSOAPProducerImportService&protocol=http
Comment 17 David Ward 2010-01-20 16:48:54 EST
I was able to trace when this issue was fixed.  (It was by me.  Boy where's my memory these days?)  Anyway, I re-opened then re-closed JBESB-3134 with a new resolution: "Duplicate Issue".  The problem was existent in r31121, but disappeared in r31122. That revision is associated with JBESB-3092, which makes sense because AbstractWsdlContractPublisher uses RemoteWsdlLoader, which I changed in that release to make sure the port number isn't getting stripped out of the re-written import URL.  So now we know *why* it should be good-to-go in ER8.  Please re-test this issue once ER8 becomes available. Thank you.
Comment 18 Jiri Pechanec 2010-02-12 05:14:37 EST
Verified in CR1

Note You need to log in before you can comment on or make changes to this bug.