Kees wrote:
> hmm, I don't think I can see any use in these new features. I will have
> to go through the
> jaxb2.0 documentation to know for sure. I hope all annotations (vendor
> specific extensions) in
> jaxb1.0 are also supported in jaxb2.0?
Let me try again.
The concept is that in 2.0 we'll generate code so simple that you can
feel comfortable modifying them. For example, given the following schema:
<xs:complexType name="point">
<xs:sequence>
<xs:element name="x" type="xs:int" />
<xs:element name="y" type="xs:int" />
</
</
XJC will give you something like and nothing else. No unmarshaller code,
no marshaller code.
List.1
public class Point {
@XmlElement int x;
@XmlElement int y;
public int getX() { return x; }
public void setX(int v) { x=v; }
public int getY() { return y; }
public void setY(int v) { y=v; }
}
If you are working with a relatively stable schema, then you can just
take these classes and put them into your source repository, and then
you can start modifying them. For example, if you want to access fields
directly, you can change above to:
List.2
public class Point {
@XmlElement public int x;
@XmlElement public int y;
}
Or maybe you can add your own method, or have it implement whatever
interface you like:
public class Point implements Comparable<Point> {
@XmlElement public int x;
@XmlElement public int y;
public boolean compareTo(Point that) {
...
}
}
And this will still marshal/unmarshal to the same XML just fine.
If unfortunately your schema changes constantly, we still haven't
figured out the complete story yet, but one approach you can take is to
consider it as tracking 3rd party source code (XJC generated code) with
local changes.
For example, you can commit List.1 into a vendor branch, then List.2
into the main trunk. Then suppose your schema changes to:
<xs:complexType name="point">
<xs:sequence>
<xs:element name="x" type="xs:int" />
<xs:element name="y" type="xs:int" />
<xs:element name="z" type="xs:int" />
</
</
Then XJC now generates:
List.3
public class Point {
@XmlElement int x;
@XmlElement int y;
@XmlElement int z;
public int getX() { return x; }
public void setX(int v) { x=v; }
public int getY() { return y; }
public void setY(int v) { y=v; }
public int getZ() { return z; }
public void setZ(int v) { z=v; }
}
If you commit this as the next revision in the vendor branch, CVS can
merge changes between List.1->List.3 (schema changes) and List.1->List.2
(your changes) and produce:
public class Point {
@XmlElement public int x;
@XmlElement public int y;
@XmlElement int z;
public int getZ() { return z; }
public void setZ(int v) { z=v; }
}
This case (of tracking changing schemas) is trickier than we'd like it
to be, and I think we are still thinking about ways to make this easier
(your input is more than appreciated!)
But I think it's still a lot of improvements than 1.0.
> I'm talking about 2 different java classes via a naming convention :
> 1. jaxb generates : generated.gti.conf.EquipmentClass
> But it should use internally the class gti.conf.EquipmentClass (see 2)
> 2. I create : gti.conf.EquipmentClass (which is a subclass from
> generated.gti.conf.EquipmentClass). In this class I can put my
> code which will
> be preserved when a new schema is created (because jaxb generates
> generated.gti.conf.EquipmentClass)
OK.
> 3. jaxb should generate methods (when using ID/IDREF) (for typesafety)
> - public void setEquipmentClass(gti.conf.EquipmentClass ec)
> - public gti.conf.EquipmentClass getEquipmentClass()
> It should NOT generate methodes like:
> - public void setEquipmentClass(Object ec)
> - public Object getEquipmentClass()
> - public void setEquipmentClass(generated.gti.conf.EquipmentClass)
> !!!!!!!!!!!!
> - public generated.gti.conf.EquipmentClass getEquipmentClass()
>
> I've managed to get 1 and 2 working in jaxb 1.0 with the annotation
> <jxb:class implClass>
> and the binding <jxb:schemaBindings><jxb:package
> name="generated.gti.conf"/>. (I don't
> like this very much but it works).
> I haven't got 3 working. Are there any ways? and in jaxb 2.0?
As I wrote earlier, not in 1.0. The point I was trying to make is that
all references to EquipmentClass, not just ID/IDREF, is generated to
generated.gti.conf.EquipmentClass, not your own gti.conf.EquipmentClass.
By this, I mean if JAXB generates another class that has EquipmentClass
as a property, the getter/setter refers to the generated one, not your
subclass.
So even without this ID/IDREF problem, you still have to constantly cast
from the generated one to your subclass. That's why I didn't find much
merit in improving just ID/IDREF.
In 2.0, we are hoping that you don't even have to use @implClass --- I
hope you'll put your own logic into the same class XJC generates. So, if
XJC generates:
class EquipmentRef {
@XmlElement @XmlIDREF
Object equipment;
...
}
and you don't like it, you can just change it to:
class EquipmentRef {
@XmlElement @XmlIDREF
Equipment equipment;
...
}
The details of annotations and actual signature could change, but I hope
you get the general direction that we are after.
Please let me know how you think about this.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net