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

Bug 348150

Summary:	descendent elements and attributes validated and available for content assist
Product:	[WebTools] Dali JPA Tools	Reporter:	Paul Fullbright <paul.fullbright>
Component:	JAXB	Assignee:	Paul Fullbright <paul.fullbright>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	neil.hauge
Version:	3.0
Target Milestone:	3.0.1
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Paul Fullbright

2011-06-02 18:55:08 EDT

Given the following schema:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema 
	xmlns:test="http://example.org/test" 
	xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
	targetNamespace="http://example.org/test">
   
   <xsd:complexType name="root">
      <xsd:sequence>
         <xsd:element name="wrapper" minOccurs="0">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element name="element" type="xsd:string"/>
               </xsd:sequence>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
   <xsd:element name="root" type="test:root"/>
</xsd:schema>

and test class:

@XmlType
@XmlRootElement(name = "root")
public class Root {
	
	@XmlElement(name = "element")
	private String element;
}


the element "element" is validated as correct, even though it exists *within* the element "wrapper" and is not a direct child of the "root" type.  When getting content assist for the @XmlElement.name() field, both "element" and "wrapper" are given as choices, even though "wrapper" is the only proper choice in this context.  (Note that if an @XmlElementWrapper(name = "wrapper") is used, then "element" is valid.)

Comment 1 Neil Hauge

2011-06-14 14:54:06 EDT

This is borderline for maintenance, but depending on the fix, it may be appropriate.

Comment 2 Paul Fullbright

2011-07-01 15:54:18 EDT

We've decided to not address this for 3.0.1.

At worst, you end up with incorrect validations.  If we fixed the bug, you could end up with incorrect invalidations (i.e. errors showing up in cases where there should be no error), particularly when used with @XmlElementWrapper.  Proper fixing would require addressing xml element wrapper validation, which considering the low impact of this bug, is out of scope for 3.0.1.

This is already addressed in head.