Brian Pontarelli wrote:
> 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.
That is correct. But as it stands today, it's somewhat difficult to use
JAXB to handle classes that are written by other people, because JAXB
imposes so many restrictions on how those classes need to look like.
> 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.
I see. It never occurred to us (at least for me) that you define a
property in the base class without making it XML-visible, and then later
down the hierarchy you make it XML-visible.
One hack way to do so is to define a property on the derived class to
make it visible.
class Base {
@XmlTransient
protected int foo;
}
@XmlType(propOrder={...,"FooForJAXB",...})
class Derived extends Base {
@XmlElement(name="foo")
private int getFooForJAXB() {
return foo;
}
private void setFooForJAXB(int value) {
foo = value;
}
}
I still think that this isn't a typical case, and it's justifiable to
make this case ugly so that the majority case can be written more concisely.
I was expecting a possibility that people define XML-visible class as
the base class, then privately extend it by adding non XML-visible
states to it, but not the other way around.
If possible, would you elaborate a bit on the various design
considerations that led you to do this?
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com