> I think we'd like to limit keys to be of a property on the same
> object. That would be a lot simpler to implement. At least, we'd like
> a key to be ready when the value object is unmarshalled (meaning the
> key must be a descendant of the value object) If we can limit it to be
> on the same object, which I think is reasonable, the key can be
> specified in terms of the property name.
>
> XPath satisfies none of those. It allows way too much flexibility.
>
> OTOH, a property name is a Java concept and it's derived by JAXB. When
> you are working on a schema, it would be nicer if you can point to the
> key by using XML terms, instead of Java terms.
>
> One data-binding tool that I saw had a mark up like this:
>
>
> <xs:complexType name="fooBar">
> ...
> <xs:element name="servlet">
> <xs:annotation><xs:appinfo>
> <property name="servlets" type="map" />
> </
> <xs:complexType>
> <xs:sequence>
> <xs:element name="servlet-name" type="xs:string"/>
> <xs:annotation><xs:appinfo>
> <key />
> </
> <xs:element name="servlet-class" type="xs:string"/>
>
> to produce something like:
>
> class FooBar {
> Map<String,Servlet> servlets;
>
> class Servlet {
> String name;
> String class;
> }
This would work fine, but at the same time, I can't ship a schema with
jaxb elements in it so it must be configurable outside of the schema as
well as inside the class.
>
> Really? Thanks! I'll ask the management to see if we can publish the
> javadoc of the RI. It has enough pluggability layer in place already
> to allow someone to work on something like this. But for that I'll
> have to work with legendary Sun lawyers once again...
>
> I think the map support would be useful without a hashCode/equal
> implementation. The above servlet sample is one such example.
Agreed, but if the Map support is blown out to support complex elements
as keys, then it is required. I could actualy see that support being
highly desirable. Consider this snippet:
<lastTripForEachUser>
<itinerary>
<user email="foo_at_bar.com" name="John Doe" age="29"/>
<record>
...
</record>
</itinerary>
...
</>
This could look like this:
public class LastTripForEachUser {
private Map<User, Itinerary> itinerary;
}
> I guess the point I was trying to make is that if you have a need to
> build a in-memory representation very different from the on-the-wire
> format, you can always use ObjectLifecycle or @XmlJavaTypeAdapter.
>
> For your custom class, I think actually you can already do this today.
> I agree that a better out-of-box binding would be highly desirable,
> and I agree that supporting such code generation from a schema would
> be also nice to have.
If there is already annotation support for this than adding it to the
XJC is just secondary. I'm not in favor of using the lifecycle support,
but if necessary than I can. I'd much rather have a clean POJO
implementation without requiring additional support classes.
How is that example of JAXB 2.0 using custom classes, external binding
definitions and all that advanced stuff coming? ;) I've very anxious to
check it out!