Brian Pontarelli wrote:
>> For example, in J2EE deployment descriptors, you define servlets like
>> this:
>>
>> <servlet>
>> <servlet-name>Stapler</servlet-name>
>> <servlet-class>org.kohsuke.stapler.Stapler</servlet-class>
>> </servlet>
>>
>> ... where <servlet-name> must be unique. Shouldn't you be able to have
>> a map from a servlet name to the following Servlet class?
>>
>> class Servlet {
>> @XmlElement
>> String servletName;
>> @XmlElement
>> Class setvletClass;
>> }
>>
>> That's what I meant by using elements as keys.
>
> Gotcha. You either way would be great. The fundamental limitation is
> that unless JAXB implements hashcode and equals for all generated
> classes, then the element used as a key must be a simple type. So, the
> customization could use XPath to determine the key?
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;
}
>> Boy so many people asks this feature!
>>
>> My current thinking is to use the plugin mechanism of the JAXB RI to
>> allow someone else to write it as a plug-in.
>>
>> If there's any interested taker, we can discuss about how it can be done.
>
> I can implement it if you need. The only concern I have is that if the
> Map support is added and elements as keys is supported, than JAXB needs
> to implement this. I can still help with the code however.
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.
>> 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.
>>
>> That's the general-purpose catch-all mechanism. For the "map support"
>> to be useful, it has to focus on a particular set of well-used use
>> cases, and it has to be easy. If it's not well-used enough, it doesn't
>> deserve to have its own mechanism. If it's not easy enough, there's no
>> point in having it at all.
>>
>> I was questioning whether this multimap functionality is well-used
>> enough to justify its special support.
>
> I would say it would be, but that's just a guess really. Either way,
> support for simple Maps with attributes or elements as keys should
> definitely be considered. Or at the least the annotations and the
> support from the (un)marshaller for it so that I can write it into my
> JAXB generated classes or my custom classes by hand.
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.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com