Brian Pontarelli wrote:
> Just makes using existing POJOs easier.
I agree.
>>
>> - you have @keyAttribute, which seems to imply that elements can't be
>> a key. This is easier to implement, but do you have any justification
>> for not allowing elements to be keys?
>
> I thought about this and wasn't sure how it would play out. Which
> elements would be keys and which would be values? XML naturally implies
> lists for sub-elements. Putting them in a Map implies that each element
> has something that identifies it as unique. The only other data
> structure I could think of would be a Set, but I'm not sure how to use
> elements as keys.
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.
> This does bring up another good point, should the generated JAXB POJOs
> implement hashcode and equals according to the XML schema? This would be
> very nice to have for clients so that they can determine if two objects
> are equal and use them as keys into Maps elsewhere in an application.
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.
>> - do you really need "retainDupliates"? If you expect duplicates,
>> would you really want to use a Map?
>>
> Well, depends I guess on the requirements. If I'dl like all shopping
> cart items by type I could have them placed into a map based on the type
> attribute. In this case the value of the Map would be a List of items. I
> think it could still be useful.
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.
>> One possible easier (for us) approach would be to design the basics so
>> that you can add this kind of functionality by deriving/modifying a
>> generated class.
>
> Yeah, that would work also. That brings us back to our discussion about
> handling modifications to generated classes. If the annotations are
> written to support this, I could just write my own POJO and use that
> with the JAXB (un)marshaller.
Right.
> But, if I want to generate the classes and
> then need to modify them to support the Map, then we need to figure out
> how JAXB should handle obejct modifications and/or additions.
Exactly.
>> This is RI-specific, but there's the com.sun.xml.bind.ObjectLifecycle
>> interface you can implement on your object (see the attached) so that
>> you can get notified when your object is unmarshalled. This will allow
>> you to set up your own Map.
>
> That would work out alright, but would be cooler if it was baked in.
> This requires more coding by the developer and the code that uses JAXB
> must know that it needs to setup an ObjectLifecycle that can handle the
> specific Object it is working it. Plus, it might require some instanceof
> and casts. Although it is more work, it would be much cooler if JAXB
> handled this stuff.
I agree that some level of Map support would be very important. I think
it's something the EG is already aware of.
> Let's return to the modification dialog we started a while back in a
> separate email and figure out if we can come up with a cool solution
> that will allow modifications to the JAXB generated classes.
Much appreciated.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com