Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 336975 - XmlAccessorType is not being inherited by sub classes
Summary: XmlAccessorType is not being inherited by sub classes
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Eclipselink (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Nobody - feel free to take it CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-11 12:07 EST by Karen Butzke CLA
Modified: 2022-06-09 10:32 EDT (History)
2 users (show)

See Also:


Attachments
Code demonstration issue. (1.73 KB, application/x-zip-compressed)
2011-02-24 13:59 EST, Blaise Doughan CLA
no flags Details
Proposed fix and test case (13.33 KB, patch)
2011-03-09 12:51 EST, Matt MacIvor CLA
no flags Details | Diff
Updated fix. (13.27 KB, patch)
2011-03-09 14:27 EST, Matt MacIvor CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Karen Butzke CLA 2011-02-11 12:07:41 EST
Generate a schema using MOXy with the following 4 classes.
@XmlType
public class Z {
	public int zAttribute;
}

@XmlTransient
@XmlAccessorType(XmlAccessType.NONE)
public class Y extends Z {
	public int yAttribute;
}

@XmlType
@XmlAccessorType(XmlAccessType.PUBLIC_MEMBER)
public class X extends Y {
	public int xAttribute;
}
@XmlType
public class X2 extends Y {
	public int copyOfXAttribute;
}

The x2 complex type is generated:
   <xsd:complexType name="x2">
      <xsd:complexContent>
         <xsd:extension base="z">
            <xsd:sequence>
               <xsd:element name="yAttribute" type="xsd:int"/>
            </xsd:sequence>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>

I don't think it should have generated the "yAttribute" element because the access type has been set to NONE in the parent class Y
Comment 1 Karen Butzke CLA 2011-02-11 15:08:12 EST
To make this what I think is a valid use case, set @XmlAccessorType(XmlAccessType.NONE) on the package-info.java and remove it from the Y class. @XmlTransient is mutually exclusive with all other jaxb annotations.

Should Dali have a validation error if any annotation is used with @XmlTransient? And should MOXy have an error or just ignore other annotations?
Comment 2 Karen Butzke CLA 2011-02-21 09:59:12 EST
I have realized that the bug here is how attributes are generated into derived classes of XmlTransient classes. It appears that they are always generated with PUBLIC_MEMBER access no matter what access is set on the XmlTransient on the derived class or in the package-info.java. The spec doesn't appear to address this use case.

The reference implementation uses the access type of the derived class for determining what attributes are generated into the schema for the transient class. This seems reasonable to me. If no access type is set on the derived class then it uses the access type that is set on the XmlTransient class. I am unsure if that last bit of behavior is correct since the XmlTransient annotation states that '@XmlTransient is mutually exclusive with all other JAXB defined annotations.'
Comment 3 Blaise Doughan CLA 2011-02-24 13:59:32 EST
Created attachment 189727 [details]
Code demonstration issue.
Comment 4 Blaise Doughan CLA 2011-03-08 10:07:56 EST
The issue is that subclasses without an XmlAccessorType specified are not inheriting the XmlAccessorType specified on the super classes.
Comment 5 Matt MacIvor CLA 2011-03-09 12:51:46 EST
Created attachment 190776 [details]
Proposed fix and test case
Comment 6 Matt MacIvor CLA 2011-03-09 14:27:36 EST
Created attachment 190786 [details]
Updated fix.
Comment 7 Matt MacIvor CLA 2011-03-10 10:11:06 EST
Attached patch has been checked in to SVN
Comment 8 Eclipse Webmaster CLA 2022-06-09 10:32:30 EDT
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink