Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338628

Summary:

Underlying WSDL EMF model does not resolve element references on DOM update

Product:

[WebTools] WTP Webservices

Reporter:

Stanislav Nichev <stanislav.nichev>

Component:

wst.wsdl

Assignee:

wst.wsdl <wst.wsdl-inbox>

Status:

REOPENED ---

QA Contact:

Keith Chong <keith.chong.ca>

Severity:

normal

Priority:

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows Vista

Whiteboard:

Attachments:

Description	Flags
sample wsdl file to reproduce the issue	none
wsdl file to reproduce the issue	none

Description Stanislav Nichev

2011-03-02 04:00:49 EST

Build Identifier: 20100917-0705

Hi Colleagues,

Probably you are aware of the following issue. I'm going to describe some simple test case on how to reproduce it:

TC#1:
Prerequisites:
1) WSDL with two namespaces
2) One structure type in the first namespace, with one child elment referencing a global element from the first namespace
3) A copy of the referenced element exists in the second namespace
4) A prefix from the first schema exists to the second one

Steps to reproduce:
1) In the source page: update the prefix to the referred element from the one for the first namespace, to the one for the second namespace
2) Although the described changes are valid, a validation error for the child element is fired: "XSD: Element reference http://yyy#xxx is unresolved"

We have done some fixes for those type of issues for the wtp.inc.sieditor project.
What we did for the wtp.inc.sieditor project is the following:
1) We check the qname for the referred element
2) We try to find a namespace matching the qname
3) We try to find the matching element
4) We set the XSDElementDeclarationReference of the child element to the found reference (XSDSchema#resolveElementDeclaration())

If you need some further information on the issue or some simple unit tests, we'll be happy to provide them.

Regards,
Stanislav


Reproducible: Always

Comment 1 Stanislav Nichev

2011-03-02 04:05:14 EST

Created attachment 190111 [details]
sample wsdl file to reproduce the issue

Short description of the WSDL:

Namespace "http://www.example.org/NewWSDLFile/" and namespace "http://namespace1" both contain the "GlobalElement" global element.

In the first namespace, there is a complex type: "StructureType1". This type has a child element referring the "GlobalElement" from the first namespace.

In order to reproduce the issue, update the prefix in 'type="tns:GlobalElement"' to 'type="ns0:GlobalElement"'

Regards,
Stanislav

Comment 2 Keith Chong

2011-03-03 11:50:17 EST

Try this:

Add this to the first inline schema

<xsd:import namespace="http://namespace1"/>

Comment 3 Stanislav Nichev

2011-03-03 12:48:37 EST

Hi Keith,

Of course this fixes the problem in the test case :)! Thank you for the info and the quick reply.

But the problem still exists - I'll try to provide a more valid "working" test case. I'll reopen the bugzilla when I do.

Regards,
Stanislav

Comment 4 Stanislav Nichev

2011-03-03 13:03:24 EST

Created attachment 190294 [details]
wsdl file to reproduce the issue

Hi Colleagues,

I've managed to find a reproducible test case:

1) Open the attached WSDL
2) Go to the source page and update (preferrably in a composite operation):
- targetNamespace of the wsdl and the xmlns:tns by adding "aaa"
- the targetNamespace of the first namespace by adding "aaa"
- the import directive of the second namespace by adding "aaa"
3) When this is one - no validation errors on the underlying EMF model
4) Execute Undo
 
The EMF model objects for the
   <wsdl:input message="tns:NewOperationRequest" /> and
   <wsdl:output message="tns:NewOperationResponse" />
messages are now "broken" and not reconciled.

The XSDElementDeclarationReference for both the child elements, referring to global elements are now "broken" as well:
- XSD: Element reference http://www.example.org/NewWSDLFile/aaa#NewOperation is unresolved
- XSD: Element reference http://www.example.org/NewWSDLFile/aaa#GlobalElement is unresolved

Similar test cases can be found for this issue, but I'm guessing the source of the problem is one and the same.

Regards,
Stanislav

Comment 5 Stanislav Nichev

2011-03-03 13:05:20 EST

I've updated the test case with a valid one and thus - reopening the bugzilla.