Random Thoughts

Serializing Domain Objects To XML Using Groovy

2009-03-22T22:59:00.001-04:00

This post is a continuation from my prior post in which we took serialized data from XML and constructed a complex domain object graph. In this post, we’ll take these populated in memory object instances of the Customer class and we will serialize them back out to XML format using Groovy and XMLSlurper. If you haven’t read the previous post on this topic I’d encourage you to stop now and do so before continuing on in order to set the context for this example.

Just as a quick refresher, here are the domain objects for our test (in order to more easily and cleanly support the approach I wanted to take, I converted the Customer domain class to a Groovy class):

Customer class

        1: package org.demo.xmldomain;

       2:  

       3: import groovy.xml.StreamingMarkupBuilder;

       4: import java.util.ArrayList;

       5: import java.util.List;

       6:  

       7: /**

       8:  * A sample customer domain class implemented as a groovy class

       9:  * @author twalters

 */

public class Customer {

  

    int id;

    String firstName;

    String lastName;

    List addresses;

  

    def Customer(){

        addresses = new ArrayList()

    }

  

    /**

     * This method returns a fully formatted name for this customer.

     * @return - a string of the format 'firstName lastName'

     */

    def String returnFullName(){

        if ("".equals(this.getFirstName()) || this.getFirstName() == null)

            return this.getLastName();

  

        if ("".equals(this.getLastName()) || this.getLastName() == null)

            return this.getFirstName();

  

        return this.getFirstName() + " " + this.getLastName();

    }

  

    def String toXML() {

        StreamingMarkupBuilder builder = new StreamingMarkupBuilder();

        def customer = {

            customer(id:this.id){

                firstName(this.firstName)

                lastName(this.lastName)

                addresses {

                    unescaped << this.buildAddressesXML()

                }

            }

        }

        builder.bind(customer)

    }

  

    def String buildAddressesXML() {

        def result = ""

        this.addresses.each{address ->

            result += address.toXML()

        }

        return result

    }

  

}

Address class

       1: package org.demo.xmldomain

       2: import groovy.xml.StreamingMarkupBuilder

       3:  

       4: /**

       5:  * This is a simple domain model class for a snail mail address.

       6:  * @author twalters

       7:  */

       8: class Address {

       9:     int id

    String addressLine1

    String addressLine2

    String city

    String state

    String postalCode

  

    /**

    * Returns the address formatted as a single line string.  If line1, city, state, or postal code are null,

    * the entire string will return null

    **/

    def String formattedAddress() {

        if (addressLine1 == null || addressLine1 == "" ||

            city == null || city == "" || state == null || state == "" ||

            postalCode == null || postalCode == "")

            return null;

  

        if (addressLine2 != null && addressLine2 != "")

            return addressLine1 + " " + addressLine2 + " " + city + ", " + state + " " + postalCode

        else

            return addressLine1 + " " + city + ", " + state + " " + postalCode

    }

  

    def String toXML() {

        def builder = new StreamingMarkupBuilder()

        def address = {

            address(id:this.id){

                "line-1"(this.addressLine1)

                "line-2"(this.addressLine2)

                city(this.city)

                state(this.state)

                "postal-code"(this.postalCode)

            }

        }

        builder.bind(address)

    }

}



The other code of interest in supporting this example is the method which drives the whole process (the class it’s in is really not relevant):

       1: public void serializeCustomersToXMLFile() {

       2:     def writer = new FileWriter("D:\\temp\\SerializedAsXML.xml")

       3:     List<Customer> customerList = this.buildCustomersFromXMLFile()

       4:     

       5:     def builder = new StreamingMarkupBuilder().bind {

       6:         unescaped << "<?xml version='1.0' encoding='UTF-8'?>"

       7:         unescaped << '<customers>'

       8:         customerList.each {cust ->

       9:             unescaped << cust.toXML()

      10:         }

      11:         unescaped << '</customers>'

      12:     }

      13:     writer << builder

      14: }

My primary objective here is to take a couple of fully populated customers (including multiple addresses for each), and to serialize them out to produce the same xml format as the xml file I’ve been reading in from my last few posts. If you haven’t been following along up til now, I tried to make the sample a bit more realistic by ensuring some key differences between my classes and the xml file (difference in names, the use of attributes, element names containing hyphens).

To serialize the objects, I’m using Groovy’s StreamingMarkupBuilder class. This class has a bind method which takes a special closure used to specify the format for your output markup. So, without further ado, the solution I present here works as follows:

For each domain class I added a toXML method which essentially knows how to generate the xml markup to represent itself. Since a customer domain class also contains zero to many address objects, the customer’s toXML method loops through each address associated with it and calls the toXML method on each address (I use a small helper method to accomplish this). Finally, the XML I’m striving to generate has some additional tags around the serialized data (<customers></customers> and some general xml information), we need another method to wrap calls to the domain classes toXML method. This method is presented above (serializeCustomersToXMLFile). Let’s walk through this method now to see what it’s doing:

On line #3 above, we generate a list of customers fully populated using a method I wrote as part of my last few posts named (buildCustomersFromXMLFile). To summarize, this method reads data from an XML file and generates a list of fully populated customers in memory using the data in the XML file. We next create an instance of the StreamingMarkupBuilder and invoke it’s bind method.

The bind method accepts a closure which is used to specify the format of the xml data. Within this bind method we loop through the list of customers and call the toXML method for each. In addition to the customer loop within the closure there are a few other things about the builder class that you should be aware of:

If you want to generate an element named ‘customer’ e.g. <customer></customer> you simply add to the closure customer. If you want to add sub-elements under ‘customer’ you do this by specifying another closure under the primary one e.g. customer {firstName addresses{line-1}}. If you want to add attributes to your customer tag this is done using syntax which looks like a method constructor. For example, to generate an id attribute for your customer you could do something like this: customer(id:variable containing the id to write out).

What’s the significance of the name ‘unescaped’ in the example. As you’ve probably guessed by now, by using this special name, we’re instructing the builder not to escape the values of the string being provided. Another special name the builder supports is ‘out’. The purpose of ‘out’ is to tell the builder that you’re passing a closure as opposed to markup to render.

In summary the StreamingMarkupBuilder class provides a simple flexible mechanism for generating xml markup. It can support highly customized xml and is fairly intuitive to use (not as easy as XmlSlurper but not too hard to wrap your head around).

==================================================================

Based on some feedback from a reader (see comment from John below) I refactored this example a bit to simplify things through the use of the builder interface. Here’s the same sample application using the new approach:

Address.Groovy

       1: package org.demo.xmldomain

       2: import groovy.xml.StreamingMarkupBuilder

       3:  

       4: /**

       5:  * This is a simple domain model class for a snail mail address.

       6:  * @author twalters

       7:  */

       8: class Address implements Buildable {

       9:     int id

    String addressLine1

    String addressLine2

    String city

    String state

    String postalCode

  

    /**

    * Returns the address formated as a single line string.  If line1, city, state, or postal code are null,

    * the entire string will return null

    **/

    def String formattedAddress() {

        if (addressLine1 == null || addressLine1 == "" ||

            city == null || city == "" || state == null || state == "" ||

            postalCode == null || postalCode == "")

            return null;

  

        if (addressLine2 != null && addressLine2 != "")

            return addressLine1 + " " + addressLine2 + " " + city + ", " + state + " " + postalCode

        else

            return addressLine1 + " " + city + ", " + state + " " + postalCode

    }

  

    def void build(GroovyObject builder){

        def address = {

            address(id:this.id){

                "line-1"(this.addressLine1)

                "line-2"(this.addressLine2)

                city(this.city)

                state(this.state)

                "postal-code"(this.postalCode)

            }

        }

        address.delegate = builder

        address()

    }

  

}

Customer.Groovy

       1: package org.demo.xmldomain;

       2:  

       3: import groovy.xml.StreamingMarkupBuilder;

       4: import java.util.ArrayList;

       5: import java.util.List;

       6:  

       7: /**

       8:  * A sample customer domain class implemented as a groovy class

       9:  * @author twalters

 */

public class Customer implements Buildable {

  

    int id;

    String firstName;

    String lastName;

    List addresses;

  

    def Customer(){

        addresses = new ArrayList()

    }

  

    /**

     * This method returns a fully formatted name for this customer.

     * @return - a string of the format 'firstName lastName'

     */

    def String returnFullName(){

        if ("".equals(this.getFirstName()) || this.getFirstName() == null)

            return this.getLastName();

  

        if ("".equals(this.getLastName()) || this.getLastName() == null)

            return this.getFirstName();

  

        return this.getFirstName() + " " + this.getLastName();

    }

  

    def void build(GroovyObject builder){

        def customer = {

            customer(id:this.id){

                firstName(this.firstName)

                lastName(this.lastName)

                addresses {

                    this.addresses.each{address ->

                        out << address

                    }

                }

            }

        }

        customer.delegate = builder

        customer()

    }

}

In both of these domain objects, note they both now implement the Buildable interface and also the required build method.

Here’s the revised driver method which generates the XML file and wraps the domain objects with a customers element.

   1: public void serializeCustomersToXMLFile() {

   2:     def writer = new FileWriter("D:\\temp\\SerializedAsXML.xml")

   3:     List<Customer> customerList = this.buildCustomersFromXMLFile()

4:

   5:     def builder = new StreamingMarkupBuilder().bind {

   6:         mkp.xmlDeclaration()

   7:         unescaped << '<customers>'

   8:         customerList.each {cust ->

   9:             out << cust

  10:         }

  11:         unescaped << '</customers>'

  12:     }

  13:     writer << builder

  14: }

Also, I updated this code to remove the hard coded xml declaration and replaced it with a call to mkp.xmlDeclaration(). Depending on the consumer of this generated xml you may or may not want to set the encoding type directly rather than letting it default to your local encoding. I ran this particular example on my windows based laptop and it sets the encoding to: "windows-1252".

Deserialization of XML using Groovy

2009-03-17T21:31:00.001-04:00

Continuing on where I left off in my last post, I’d like to briefly explore going from xml to domain objects using Groovy and more specifically XmlSlurper. In order for this to be a reasonable example, we’ll use the same xml format and domain objects that I’ve used in the last couple of posts. I’ve included the code again here in case you haven’t been following this chain of posts on XmlSlurper (if you’re new to XmlSlurper you might want to check out my other posts on the topic for a quick tutorial).

Our business domain for this exercise consists of a Customer class and an Address class. In our domain, a customer has an id number, a first name, a last name, and zero or more addresses. An address consists of an id number, line1, line2, city, state, postal code.

Customer class (Java):

        1: public class Customer {

       2:  

       3:     private int id;

       4:     private String firstName;

       5:     private String lastName;

       6:     private List addresses;

       7:  

       8:     public Customer() {

       9:         addresses = new ArrayList();

    }

  

    public List getAddresses() {

        return addresses;

    }

  

    public void setAddresses(List address) {

        this.addresses = address;

    }

  

    public void addAddress(Address anAddress){

        if(this.addresses == null)

            this.addresses = new ArrayList();

        

        this.addresses.add(anAddress);

    }

  

    public void removeAddress(Address anAddress){

        this.addresses.remove(anAddress);

    }

  

    public int getId() {

        return id;

    }

  

    public void setId(int id) {

        this.id = id;

    }

  

    public String getFirstName() {

        return firstName;

    }

  

    public void setFirstName(String firstName) {

        this.firstName = firstName;

    }

  

    public String getLastName() {

        return lastName;

    }

  

    public void setLastName(String lastName) {

        this.lastName = lastName;

    }

  

    /**

     * This method returns a fully formatted name for this customer.

     * @return - a string of the format 'firstName lastName'

     */

    public String returnFullName(){

        if ("".equals(this.getFirstName()) || this.getFirstName() == null)

            return this.getLastName();

  

        if ("".equals(this.getLastName()) || this.getLastName() == null)

            return this.getFirstName();

        

        return this.getFirstName() + " " + this.getLastName();

    }

  

}

Address class (Groovy):

       1: class Address {

       2:     int id

       3:     String addressLine1

       4:     String addressLine2

       5:     String city

       6:     String State

       7:     String postalCode

       8:  

       9:     /**

      10:     * Returns the address formated as a single line string.  If line1, city, state, or postal code are null,

      11:     * the entire string will return null

      12:     **/

      13:     def String formattedAddress() {

      14:         if (addressLine1 == null || addressLine1 == "" ||

      15:             city == null || city == "" || state == null || state == "" ||

      16:             postalCode == null || postalCode == "")

      17:             return null;

      18:  

      19:         if (addressLine2 != null && addressLine2 != "")

      20:             return addressLine1 + " " + addressLine2 + " " + city + ", " + state + " " + postalCode

      21:         else

      22:             return addressLine1 + " " + city + ", " + state + " " + postalCode

      23:     }

      24: }

      25:

XML format for our serialized data (populated with data):

       1: <?xml version='1.0' encoding='UTF-8'?>

       2: <customers>

       3:     <customer id='12345'>

       4:             <firstName>FirstOne</firstName>

       5:             <lastName>FirstLastName</lastName>

       6:             <addresses>

       7:           <address id='11'>

       8:             <line-1>first address line1</line-1>

       9:             <line-2>first address line2</line-2>

            <city>first-city</city>

            <state>first-state</state>

            <postal-code>first-postal</postal-code>

          </address>

          <address id='22'>

            <line-1>second address line1</line-1>

            <line-2>second address line2</line-2>

            <city>second-city</city>

            <state>second-state</state>

            <postal-code>second-postal</postal-code>

          </address>

            </addresses>

    </customer>

    <customer id='67890'>

            <firstName>SecondOne</firstName>

            <lastName>SecondLastName</lastName>

            <addresses>

          <address id='33'>

            <line-1>third address line1</line-1>

            <line-2>third address line2</line-2>

            <city>third-city</city>

            <state>third-state</state>

            <postal-code>third-postal</postal-code>

          </address>

          <address id='44'>

            <line-1>fourth address line1</line-1>

            <line-2>fourth address line2</line-2>

            <city>fourth-city</city>

            <state>fourth-state</state>

            <postal-code>fourth-postal</postal-code>

          </address>

        </addresses>    

    </customer>

</customers>

In order to make things a bit closer to something you might find in a real world setting, I set this example up such that the xml element names didn’t always match the property names in the domain classes.

The following method reads the xml from a file into memory using the XmlSlurper class. It then walks the XML graph and constructs a fully populated domain (an array list of customers with each having multiple addresses). Here’s the sample code:

       1: public List<Customer> buildCustomersFromXMLFile() {

       2:     def customerBeans = new ArrayList()

       3:     def file = new File("D:\\temp\\AdvancedExample.xml")

       4:     def customers = new XmlSlurper().parse(file)

       5:     def customerBean

       6:     customers.children().each {customer ->

       7:         customerBean = new Customer()

       8:         def custId = customer.@id

       9:         if(custId != "")

    customerBean.id = Integer.parseInt(custId.toString())

        customerBean.firstName = customer.firstName

        customerBean.lastName = customer.lastName

  

        customer.addresses.children().each {address ->

            def anAddress = new Address()

            def id = address.@id

            if(id != "")

    anAddress.id = Integer.parseInt(id.toString())

            

            anAddress.addressLine1 = address.'line-1'

            anAddress.addressLine2 = address.'line-2'

            anAddress.city = address.city

            anAddress.state = address.state

            anAddress.postalCode = address.'postal-code'

            customerBean.addresses << anAddress

        }

        customerBeans << customerBean

    }

    return customerBeans

}

This code is pretty straightforward. The only thing I’d like to call to your attention is the extra bit of code I needed to add to deal with the id attribute. The problem here is that strings in groovy are gstrings and not strings. This required me to add a toString method call to the variable before I could pass it into the Integer.parseInt method.

Here’s the test harness which invokes this method and displays the values from the deserialized objects in the console window:

       1: public static void main(String[] args) {

       2:     GreetingProvider provider = new GreetingProvider();

       3:     List customers = provider.buildCustomersFromXMLFile();

       4:     Iterator iterator = customers.iterator();

       5:     while (iterator.hasNext()){

       6:         Customer customer = (Customer)iterator.next();

       7:         System.out.println("Id: " + customer.getId());

       8:         System.out.println("First Name: " + customer.getFirstName());

       9:         System.out.println("Last Name: " + customer.getLastName());

      10:         Iterator additerator = customer.getAddresses().iterator();

      11:         while (additerator.hasNext()){

      12:             Address address = (Address)additerator.next();

      13:             System.out.println("Id: " + address.getId());

      14:             System.out.println("Address: "+ address.formattedAddress());

      15:         }

      16:     }

      17: }

In my next post, we’ll take these populated domain objects and serialize them back out to XML in the same format as the xml in this example.

More XML Processing With XMLSlurper

2009-03-14T16:01:00.001-04:00

in a previous post I explored how simple processing XML can be with Groovy using XMLSlurper. The example was fairly simple and it occurred to me that it would be helpful to beef up my example to cover some of the other aspects of working with XML using XMLSlurper. More specifically, with this post, I’d like to offer a more robust example to cover the following:

1. Referencing an element that does not exist

2. Verify that XMLSlurper is case sensitive

3. How to extract attributes from the xml

4. How to reference xml elements which contain a hyphen

5. Walking a more complex nested graph

For each example in this post, we’ll use the following xml which is housed in a file to demonstrate the features we’re going to explore.

        1: <?xml version='1.0' encoding='UTF-8'?>

       2: <customers>

       3:     <customer id='12345'>

       4:             <firstName>FirstOne</firstName>

       5:             <lastName>FirstLastName</lastName>

       6:             <addresses>

       7:           <address id='11'>

       8:             <line-1>first address line1</line-1>

       9:             <line-2>first address line2</line-2>

            <city>first-city</city>

            <state>first-state</state>

            <postal-code>first-postal</postal-code>

          </address>

          <address id='22'>

            <line-1>second address line1</line-1>

            <line-2>second address line2</line-2>

            <city>second-city</city>

            <state>second-state</state>

            <postal-code>second-postal</postal-code>

          </address>

            </addresses>

    </customer>

    <customer id='67890'>

            <firstName>SecondOne</firstName>

            <lastName>SecondLastName</lastName>

            <addresses>

          <address id='33'>

            <line-1>third address line1</line-1>

            <line-2>third address line2</line-2>

            <city>third-city</city>

            <state>third-state</state>

            <postal-code>third-postal</postal-code>

          </address>

          <address id='44'>

            <line-1>fourth address line1</line-1>

            <line-2>fourth address line2</line-2>

            <city>fourth-city</city>

            <state>fourth-state</state>

            <postal-code>fourth-postal</postal-code>

          </address>

        </addresses>    

    </customer>

</customers>

Here’s the test method that I’ll use to try touch on each point:

       1: public void processAdvancedXMLFile(String fileName)

       2: {

       3:     def file = new File("D:\\temp\\AdvancedExample.xml")

       4:     def customers = new XmlSlurper().parse(file)

       5:  

       6:     println("customers: " + customers)

       7:     println("customers: " + customers.customer)

       8:  

       9:     println("Bogus element: " + customers.bogusField)

    println("Case Matters: " + customers.customer[0].FIRSTNAME)

    println("Customer ID Number: " + customers.customer[0].@id)

  

    println("All Customer first names: " + customers.customer.firstName)

    println("First Customer's first names: " + customers.customer[0].firstName)

  

    println("All Customer last  names: " + customers.customer[0].lastName)

  

    //walk the entire xml tree

    println("Walking the entire xml tree using xmlslurper")

    customers.children().each {customer ->

        println("First Name: " + customer.firstName)

        println("Last Name: " + customer.lastName)

  

        customer.addresses.children().each {address ->

            println("Address id: " + address.@id)

            println("Address line 1: " + address.'line-1')

            println("Address line 2: " + address.'line-2')

            println("Address city: " + address.city)

            println("Address state: " + address.state)

            println("Address postal-code: " + address.'postal-code')

        }

        println("============================================")

    }

  

}

Finally, here’s the output window for a sample run:

       1: customers: FirstOneFirstLastNamefirst address line1first address line2first-cityfirst-statefirst-postalsecond address line1second address line2second-citysecond-statesecond-postalSecondOneSecondLastNamethird address line1third address line2third-citythird-statethird-postalfourth address line1fourth address line2fourth-cityfourth-statefourth-postal

       2: customers: FirstOneFirstLastNamefirst address line1first address line2first-cityfirst-statefirst-postalsecond address line1second address line2second-citysecond-statesecond-postalSecondOneSecondLastNamethird address line1third address line2third-citythird-statethird-postalfourth address line1fourth address line2fourth-cityfourth-statefourth-postal

       3: Bogus element: 

       4: All Customer first names: FirstOneSecondOne

       5: First Customer's first names: FirstOne

       6: Case Matters: 

       7: Customer ID Number: 12345

       8: All Customer last  names: FirstLastName

       9: Walking the entire xml tree using xmlslurper

First Name: FirstOne

Last Name: FirstLastName

Address id: 11

Address line 1: first address line1

Address line 2: first address line2

Address city: first-city

Address state: first-state

Address postal-code: first-postal

Address id: 22

Address line 1: second address line1

Address line 2: second address line2

Address city: second-city

Address state: second-state

Address postal-code: second-postal

============================================

First Name: SecondOne

Last Name: SecondLastName

Address id: 33

Address line 1: third address line1

Address line 2: third address line2

Address city: third-city

Address state: third-state

Address postal-code: third-postal

Address id: 44

Address line 1: fourth address line1

Address line 2: fourth address line2

Address city: fourth-city

Address state: fourth-state

Address postal-code: fourth-postal

============================================

BUILD SUCCESSFUL (total time: 6 seconds)

One nice aspect of working with XMLSlurper is that it returns an empty string instead of null anytime an element is not found. Another key aspect of working with XMLSlurper is that it’s case sensitive. If you ask XMLSlurper for an element that does not exist or use the improper case for an element you’ll get back an empty string as the response.

In my example, I first requested an element which does not exist: customers.bogusField followed next by one that does exist (firstName) but I tried to retrieve it using the wrong case (FIRSTNAME). In the output window you can see that nothing comes back in either case.

The next item from my list is to show how easy it is to pull attributes from the xml. Accessing these attributes is just as easy as accessing elements. The format is only slightly different. Where customers.customer[0].firstName would grab the first customer in the xml doc and print out the contents of the firstName element, to instead grab an attribute from the first customer element you would write: customers.customer[0].@nameOfAttribute (in the example provided I pulled the id attribute from the customer using the following code: customers.customer[0].@id

The next item on my list is one of the few quirky things I’ve uncovered when working with XMLSlurper. If your XML element name has a hyphen in the name you must tweak your syntax just a bit. It helps to understand why you must do this. The reason for this is because Groovy sees this as a minus sign instead of a hyphen. In order to instruct Groovy not to treat this hypen as a minus sign you simply need to enclose the element name in single quotes.

Here are a couple of lines from my example above which illustrate this:

println("Address line 1: " + address.'line-1')
println("Address line 2: " + address.'line-2')

Walking a more complex tree is the next item I wanted to address. The example presented here has multiple customers within the customer tag with each customer in turn having simple elements (firstName, lastName) as well as multiple addresses. The provided example walks this tree and prints out all of the element values using the children() method with a Groovy closure. I don’t show it in the example but it’s also very easy to print out the name of the XML element by using the ‘name’ method. Here’s an example for doing that:

println("Prints firstName: " + customers.customer[0].firstName.name())

In a future post I’ll devote some time to moving data between domain objects and xml.

==================================================================

An example of pulling elements from an atom feed:

Since someone asked, I’ve added a sample which pulls an id element from a sample atom feed (you can find this sample on wikipedia):

       1: def data = '''<?xml version="1.0" encoding="utf-8"?>

       2: <feed xmlns="http://www.w3.org/2005/Atom">

       3:   <title>Example Feed</title>

       4:   <subtitle>A subtitle.</subtitle>

       5:   <link href="http://example.org/feed/" rel="self"/>

       6:   <link href="http://example.org/"/>

       7:   <updated>2003-12-13T18:30:02Z</updated>

       8:   <author>

       9:     <name>John Doe</name>

      10:     <email>johndoe@example.com</email>

      11:   </author>

      12:   <id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>

      13:   <entry>

      14:     <title>Atom-Powered Robots Run Amok</title>

      15:     <link href="http://example.org/2003/12/13/atom03"/>

      16:     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>

      17:     <updated>2003-12-13T18:30:02Z</updated>

      18:     <summary>Some text.</summary>

      19:   </entry>

      20: </feed>'''

      21:  

      22:  def atomData = new XmlSlurper().parseText(data)

      23:  println("Sample output from our xml atom feed:")

      24:  println("id for the feed: " + atomData.id)

      25:  println("id for the entry: " + atomData.entry.id)

      26:  

      27:  

      28:

You can also setup XmlSlurper to be aware of your namespaces if needed. Here’s an example to show how to use that:

       1: public void processXmlWithNamespaces(){

       2:     def loanXml =

       3:     '''<loan

       4:           xmlns:customer="urn:somecompany:customers"

       5:           xmlns:account="urn:somecompany:accounts">

       6:           <customer:name>Joe Customer</customer:name>

       7:           <account:name>First Mortgage</account:name>

       8:           <periods>360</periods>

       9:        </loan>'''

      10:  

      11:     def loan = new XmlSlurper().parseText(loanXml)

      12:  

      13:     println("combined name: " + loan.name)

      14:     def ns = [:]

      15:     ns.customer = "urn:somecompany:customers"

      16:     ns.account = "urn:somecompany:accounts"

      17:     loan.declareNamespace(ns)

      18:  

      19:     println("customer name: " + loan.'customer:name')

      20:     println("account name: " + loan.'account:name')

      21: }

note the single quotes around the ‘account:name’ and ‘customer:name’. These are needed for the same reason as the quotes around the hyphen.

Here’s the output from a sample run:

       1: combined name: Joe CustomerFirst Mortgage

       2: customer name: Joe Customer

       3: account name: First Mortgage

If you want to learn more about XmlSlurper I’d also highly recommend the book:

Groovy Recipes by Scott Davis

The format for the namespace example presented above came from his excellent book (Scott’s a good presenter too if you ever have the opportunity to hear him speak).

Spring Framework Redux

2009-03-06T22:32:00.002-05:00

This is my second attempt at this article. The version of this post I originally wrote wasn’t one of my finer works. I decided that I needed to clean it up to try and explain myself a bit more clearly but by the time I had finished, the article was so much different than before that I decided it best to simply submit this one as a new post (and remove the prior post). I’ll soon write a new post where I concentrate more on AOP but for now I’m focused on trying to provide a bit of clarity around Dependency Injection. Hopefully, this version is a bit easier to read.

Spring is based on the idea that loosely coupled systems can adapt and change more quickly while at the same time allowing the developer to focus their concerns on the business problem. The framework utilizes two very powerful architectural concepts, Aspect Oriented Programming (AOP), and an implementation of the Inversion of Control (IOC) design pattern also known as Dependency Injection (DI). If you’re not already familiar with this particular design pattern I’d recommend that you start here: Martin Fowler's Site

Aspect Oriented Programming

First, let’s discuss Aspect Oriented Programming (AOP). When building complex software applications, each business component (say a controller in a typical MVC framework) in addition to solving the business problem at hand typically needs to handle various concerns which cut horizontally across the application (examples include transaction management, logging, performance profiling, and security logic.). The idea behind AOP is to pull these cross-cutting concerns out of the business layer and to ‘weave’ the code to handle these into your classes either at compile time through byte code manipulation or at run time using some form of interceptor logic (think servlet filters). Spring provides a robust implementation of AOP which provides great flexibility in allowing developers to pull code related to these cross cutting concerns from their business logic. If you’re not familiar with AOP, I’d encourage you to read the following: up in more detail on the topic: AOP explained or take a look at AspectJ for an alternative implementation.

Dependency Injection(DI)

As simply as I can describe it, Dependency Injection is a strategy used to reduce the compile time dependency between two objects (in favor instead of injecting the dependency at run-time). Probably the simplest way to wrap your brain around the value that DI can bring to your software solution is to begin with the type of problem it typically helps to solve and work through a few iterative improvements to the design (of course since this is a post about the benefits of using the Spring framework, I’m sure you can guess where we’ll end up).

Let’s begin with our sample domain model. In our business domain we have multiple performers: Some of these performers sing, some dance, and some have some specialized skill like juggling. To model this relationship I’d typically have a Performer interface with a generic perform method. I’d then have a few implementation classes for each specialization.

   1: public interface Performer {

   2:     public void perform();

   3: }

4:

5:

   6: public class Dancer implements Performer {

   7:     public void perform() {

   8:         System.out.println("I love to dance");

   9:     }

  10: }

11:

12:

  13: public class Singer implements Performer {

  14:     public void perform() {

  15:         System.out.println("I love to sing");

  16:     }

  17: }

18:

19:

  20: public class Juggler implements Performer {

  21:     public void perform() {

  22:         System.out.println("I love to juggle");

  23:     }

  24: }

In the sample above we have a Dancer, Singer, and a Juggler. Each of these classes implement the Performer interface. In the perform method for each class we’ll just have them print out what they like to do. The Dancer’s perform method would just say ‘I love to dance’ for example.

Now let’s create a sample program to consume one of these implementations as follows:

   1: Performer perf1 = new Dancer();

   2: perf1.perform();

This is a pretty common pattern that we would likely encounter in many applications. This first example simply prints out: I love to Dance.

The primary issue with this simplistic snippet of code is the compile time dependency on the Dancer class. If this type of domain were used in a real application you would probably have dozens of these compile time dependencies spread throughout the application. This is fine if requirements never change but when dealing with real world systems requirements always change. What happens if the requirements for the application change and now we need the ability to support a Singer and a Juggler in addition to the Dancer. You have hard coded calls to the Dancer constructor littered throughout the codebase which will need to be changed to support this new requirement.

Time to re-factor our solution. For the next pass let’s drop in an implementation of the factory pattern to see if it helps.

   1: public interface PerformerFactory {

   2:     public Performer createPerformer();

   3: }

4:

   5: public class DancerFactory implements PerformerFactory {

   6:     public Performer createPerformer() {

   7:         return new Dancer();

   8:     }

   9: }

10:

  11: public class JugglerFactory implements PerformerFactory {

  12:     public Performer createPerformer() {

  13:         return new Juggler();

  14:     }

  15: }

16:

  17: public class SingerFactory implements PerformerFactory {

  18:     public Performer createPerformer() {

  19:         return new Singer();

  20:     }

  21: }

So what have we accomplished. Not much as it turns out. We’ve succeeded in centralizing the code which creates each of the concrete performer classes to a single place (e.g. the DancerFactory should be used to create Dancers). The problem is that now we would have hard coded references to the DancerFactory all over our codebase. What else can we do here? Well I can think of two sub-optimal options and one much better one. Let’s start with the two sub-optimal choices:

First, I guess we could tweak our Factory model a bit and have a static method in a single PerformerFactory class which takes a string as an input parameter and returns an instance of the appropriate type of performer based on it’s value (the string could be read from a properties file). Here’s what that code might look like (remember this is a SUB-OPTIMAL solution).

   1: public class BasePerformer {

   2:     public static final String DANCER = "Dancer";

   3:     private static final String JUGGLER = "Juggler";

   4:     private static final String SINGER = "Singer";

5:

   6:     public static Performer getPerformer(String performerType){

   7:         if(DANCER.equalsIgnoreCase(performerType))

   8:             return new Dancer();

   9:         if(JUGGLER.equalsIgnoreCase(performerType))

  10:             return new Juggler();

  11:         if(SINGER.equalsIgnoreCase(performerType))

  12:             return new Singer();

13:

  14:         return null;

  15:     }

16:

  17: }

So what’s wrong with this solution? For one thing as your domain grows this method would just continue to grow. Also, you must make a source code change to swap out one of the types.

The next possible solution I could think of would be to provide a parameter in a properties file using a fully qualified class name. We could then write a bit of generic code to instantiate an instance of this class. This would work but the heavy use of reflection is typically frowned upon. Also it just seems a bit clunky.

   1: /**

   2:  * This method reads in a Performer property from the myFile.properties file

   3:  * and instantiates an instance of the class specified.

   4:  * @return an implementer of the Performer interface

   5:  */

   6: public Performer createAPerformer() {

   7:     String PERFORMER = "Performer";

8:

   9:     Properties properties = new Properties();

10:

  11:     try {

  12:         properties.load(new FileInputStream("myFile.properties"));

  13:         String value = properties.getProperty(PERFORMER);

  14:         ClassLoader cl = this.getClass().getClassLoader();

  15:         Class ourClass = cl.loadClass(value);

  16:         return (Performer)ourClass.newInstance();

  17:     } catch (IOException ex) {

  18:         Logger.getLogger(BasePerformer.class.getName()).log(Level.SEVERE, null, ex);

  19:     } catch (InstantiationException ex) {

  20:         Logger.getLogger(BasePerformer.class.getName()).log(Level.SEVERE, null, ex);

  21:     } catch (IllegalAccessException ex) {

  22:         Logger.getLogger(BasePerformer.class.getName()).log(Level.SEVERE, null, ex);

  23:     } catch (ClassNotFoundException ex) {

  24:         Logger.getLogger(BasePerformer.class.getName()).log(Level.SEVERE, null, ex);

  25:     }

26:

  27:     return null;

  28: }

The above example assumes you have a property defined in a file named ‘myFile.properties’. The property in question should look something like this:

   1: Performer = Dancer

Now that we’ve looked at a couple of sub-optimal solutions, let’s look at how a DI container provides a more robust solution to this problem.

Spring takes our previous solution another step forward and wires the factory details via xml configuration files rather than by using random property files in your code. Additionally, the objects are created when the application context is initialized which provides an added benefit of letting you know if you have any class mapping issues when the application starts as opposed to when the application uses the classes you’ve referenced (if you mistype the fully qualified class name for example).

Let’s continue our example and see how spring might help to improve upon our design. Using spring, I would now create an xml context file that looks basically like this:

   1: <bean>

   2:     <id="performer"> </id>

   3:     <class="org.demo.perform.Dancer"></class>

   4: </bean>

In order to effectively use this in my application, I must do the following:

1. Create an instance of the Spring application context passing my xml configuration file name to the constructor. This would typically be done as part of your application startup (perhaps in your main method in the case of a console application).

   1: ApplicationContext ctx = new FileSystemXmlApplicationContext("spring.xml");

2. To use the bean defined in the application code I can ask Spring to serve up an instance of the bean I need by using the id I provided in the xml configuration file. In my example the id we are looking for is “Performer”.

   1: Performer perf1 = ctx.getBean(“Performer”);

   2: perf1.perform();

With our example as it is currently configured, Spring would serve up a Dancer instance any time you ask for a Performer. If we wanted to change this to serve up a Singer instead, we could accomplish this by changing the performer bean in our Spring.xml file.

   1: <bean>

   2:     <id="performer"></id>

   3:     <class="org.demo.Singer"></class >

   4: </bean >

At this point, you might be thinking, what makes this any better than the reflection example presented earlier? This is a legitimate questions. Ignoring for the time being that writing and maintaining that extra bit of infrastructure code has a cost associated with it (and also the fact that most developers on your team would be totally intimidated by the reflection code used no matter how simple it is). Let’s take a look at what else Spring can do for us.

Let’s go back to our earlier example and assume that our Performer interface has a talent attribute which stores each performer’s specialization. We’ll add the following two methods to our interface:

   1: public Talent getTalent()

   2: public void setTalent(Talent talent)

Our new class Talent has a couple of attributes but for the purpose of this example we can assume it has a single field which contains a string to identify a given performer’s talent. So let’s have the constructor in that class take a string and use it to initialize the talent with it:

   1: public talent(String talent){

   2:     this.talent = talent;

   3: }

Now, if we go back to our reflection or factory examples and tried to support this new requirement, our solution would need some additional work to support the new domain. This makes the code brittle. Spring on the other hand, provides a mechanism for defining the dependency in the configuration file thus pulling these implementation specific details out of the code and into your master configuration file (Spring.xml in my example). The updated configuration file for Spring would now look something like this:

   1: <bean>

   2:     <id="Talent"></id>

   3:     <class="org.demo.Talent"></class>

   4:     <value="Dances"></value>

   5: </bean>

   6: <bean>

   7:     <id="Performer"></id>

   8:     <class="org.demo.Dancer"></class>

   9:     <name="talent" ref="Talent"></name>

  10: </bean>

Summary

If I’ve done a reasonable job of explaining things, you should now be able to see how a DI container such as Spring can help you to build systems which are loosely coupled. Spring is available as a framework for Java as well as .NET. If you would like to learn more about the framework and the value it might add to your next project check out the Spring website