XmlBeanUtils – Working with XML Easily

Edit:A new version was released, see here for notes.

My team and I were working the recently on a “Converter” utility whose job it is to take in a String and output one of our domain objects.

The String contains a chunk of XML conforming to a provided Schema, and in all honestly the mappings are incredibly simple. It would take far more time and code to configure XStream or JaxB than it would for me to express, on a field by field basis, what goes where.

After parsing the XML into the appropriate Java DOM objects, I noticed that retrieving values from the DOM is far more complex than seems necessary. What I really wanted was a tool that took in XML and spit out something like a DynaBean.

I honestly thought it felt like an obvious use case, but after searching for twenty minutes I couldn’t turn up a single framework or library that did what I actually wanted.

So I made one.

XmlBeanUtils is an open-source library that does the very simple job of pumping raw XML into an easy-to-query bean. It’s an extension to the BeanUtils, which is required as a transitive dependency.

XmlBeanUtils 1.0.0 provides the simplest useful utility I could come up with to work with Xml:

import com.codequirks.xmlbeanutils.XmlDynaBean;

public class Example {
    public static void main(String[] args) throws Exception {
        String randomXml = 
           "<root style=\"metasyn-tastic\" description=\"full of gibberish\">" +
                "<child name=\"foo\">Hello!</child>" +
                "<child name=\"bar\">World!</child>" +
                "<step-child name=\"baz\">" +
                    "<grandchild>Random Data</grandchild>" +
                "</step-child>" +
                "<child name=\"zap\">Goodbye.</child>" +

        XmlDynaBean root = new XmlDynaBean(randomXml);

        /* Output: root */

        /* Output: metasyn-tastic */

        /* Output: full of gibberish */

        /* children will contain foo, bar, and zap */
        List<XmlDynaBean> children = (List<XmlDynaBean>) root.get("child");

        /* step-children will contain baz */
        List<XmlDynaBean> stepChildren = (List<XmlDynaBean>) root.get("step-child");

        /* family will contain foo, bar, baz and zap */
        List<XmlDynaBean> family = (List<XmlDynaBean>) root.get("*");

        /* You can get nth child as well (zero-indexed) */
        /* Output: bar */
        XmlDynaBean bar = root.get("child", 1);

        /* You can get grab child-attributes quickly for the 0th named child */
        /* Output: foo */
        System.out.println(root.get("child", "@name"));
        /* Output: baz */
        System.out.println(root.get("step-child", "@name"));
        /* Output: foo */
        System.out.println(root.get("*", "@name"));

        /* But getting attributes of the nth child is also pretty easy */
        /* Output: zap */
        System.out.println(root.get("child", 2).get("@name"));
        /* Grabbing the grand-children of the 0th named child also works */
        /* Output: baz */
        List<XmlDynaBean> grandChildren = 
                                (List<XmlDynaBean>) root.get("step-child", "*");

Currently XmlDynaBeans are read-only.

Plans for the near future:

  • A mutable XmlDynaBean so you can “change” the XML
  • The ability for XmlDynaBeans to generate their String XML representation
  • Proper Javadocs
  • Beefig up the Google Code landing page

I would love some feedback. Please leave your comments below

  • Has this already been done before?
  • Is this useful?
  • What should I add?
  • Have you noticed any unexpected behaviour?
  • Advertisements

4 comments on “XmlBeanUtils – Working with XML Easily

  1. Pingback: XmlBeanUtils « Developing Code, Connecting Industry

  2. This is not useful.

    Given the example, I would MUCH rather use xpath.
    Also, I cannot trust this for performance, as there is no info/example for anything larger than 10 lines of XML so I would rather use straight jaxb.

    I’m not saying that handling XML in Java is as simple as it should be, but this just seems clunky. Unfortunately this is a problem that you will not be able to solve by yourself, it will take a community.

    • Thanks for the feedback. Keep in mind the first release literally took a day or two of work, and focused around the requirements I’m currently experiencing with my team.

      The main focus is working with an object tree instead of an XML tree. This is why XPath capability was not included in the very first release, though it will be added in the near future. The use case I was trying to fill is based on the fact that I don’t want to really even know or care that the data was originally XML.

      As for performance, it’s about as heavy as your average DOM parser. DOM pretty much always loads the entire tree into memory, and so would this. I’ll consider doing some testing around how big the result actually is, it could be very useful information.

      What use cases would you like to see filled by a library such as this?

  3. Great thing you did. This utility is for real world developers. Having XPath in EL expressions would be a better way – but it isn’t. So your tool is realy great!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s