Kohsuke Kawaguchi wrote:
> Brian Pontarelli wrote:
>
>> I just pulled down the latest JAXB 2.0 EA release and started
>> converting my classes to use it. Classes that were previously working
>> are not longer working for some reason.
>>
>> I have two classes:
>>
>> public class Response {
>> private Status status;
>> }
>>
>> @XmlType(name = "", propOrder = {"status", "data"})
>> public class AuthenticationResponse extends Response {
>> private Data data;
>> }
>>
>> My XSD is something like this (I coded these classes by hand, so the
>> XSD isn't really used, but still important):
>>
>> <xsd:element name="authenticateResponse">
>> <xsd:complexType mixed="false">
>> <xsd:sequence>
>> <xsd:element name="status" type="status"/>
>> <xsd:element name="data" type="data" minOccurs="0"/>
>> </xsd:sequence>
>> </xsd:complexType>
>> </xsd:element>
>>
>> I'm getting this error when running a marshalling operation:
>>
>> Property status appears in @XmlType.propOrder, but no such property
>> exists this problem is related to the following location:
>> at AuthenticateResponse
>> at public AuthenticateResponse
>> ObjectFactory.createAuthenticateResponse()
>> at ObjectFactory
>
>
> the properties of the base class always appear before those of a
> derived class, so I think you only need to say propOrder={"data"}.
>
> And currently, the order properties show up in XML is the order they
> are defined in the Java source code, so actually you don't have to
> write propOrder at all (although there's a quite lengthy tricky issue
> behind this)
Unless I write my own Java class, in which case I can reorder properties
and methods however I want. I wouldn't rely on ordering inside the Java
code for validation, unless I'm misunderstanding you.
>
>> It appears that JAXB no longer allows me to refactor my elements into
>> base classes for some reason. It cannot find the status member even
>> though it exists on the Response base class. This used to work with
>> the previous JAXB 2.0 release. Am I missing something?
>
>
> I think the current behavior is correct. I think requiring members of
> the base type to be before those of the derived types is a reasonable
> limitation, and I don't think you want to list all the base type
> property names every time you define propOrder for a derived type.
>
> How do you think?
>
The problem is still ordering. The JavaDoc says that the propOrder is
for sequences in XML types. If I refactor things into base classes that
are NOT XML types and that contain properties that are late in the
ordering of a sequence, I have no choice but to define a propOrder in
the sub-classes right? Otherwise the ordernig of the properties is lost.
If the base class is an XML type I should be fine moving the propOrder
up. But if it isn't, then I'm in a pickle.