How about walking the JAXB Java Bean tree with XPath ? JXPath does
provide a solution but it would be nicer if we can query the JAXB Java
Bean tree with XPath that one uses to query XML DOM. This XPath would be
unaware of any customizations that JAXB codegen has introduced.
Introducing an annotation into Generated Code to store the XPath would
be one to implement this.
I am not sure if you intended intended something on these lines.
I think this will be very useful and reduce number of lines one needs
while querying Java Bean tree.
Btw, This topic was previously discussed.[1]
-Prashant
[1]:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0302&L=jaxb-interest&P=16107
Kenny MacLeod wrote:
> Folks,
>
> I have an idea for a possible enhancement to JAXB which I'd like to
> throw open to the floor. It would involve a new annotation type which
> takes an XPath expression, and uses that expression to bind to the field
> /property being annotated.
>
> This could come in handy when binding to XML documents which are not
> conveniently structured, perhaps those with too many levels of
> structure, allowing you to flatten out the structure in your class model.
>
> For example, take the following XML fragment:
>
> <book>
> <title>The Dice Man</title>
> <catalog>
> <isbn>0006513905</isbn>
> </catalog>
> </book>
>
> Let's say that I don't want the <catalog> intermediary type, but to
> flatten tht <title> and <isbn> together into the same type.
>
> With the new annotation, I could do something like this:
>
> public class Book {
>
> @XmlElement
> String title;
>
> @XPath(path="catalog/isbn")
> String isbn;
> }
>
> When the JAXB runtime finds the @XPath annotation, it would evaluate
> it against the "current" node, i.e. the <book>, and assign the result
> to the field.
>
> This concept could be taken much further - you could have an annotated
> class which cherry-picks pieces of data from deep inside the node
> structure and flattens them out. The ability to mix and match this
> approach with other JAXB binding constrructs would be quite powerful,
> I think.
>
> Any thoughts?
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com