Castor, one of the few Java-XML binding tools available, is written in Java and performs data binding meant solely for the Java language. It is not the latest API to parse XML and should not be confused with something like DOM, SAX, or JDOM. However, Castor does use SAX to perform XML parsing, so you indirectly end up using SAX whenever you use Castor’s marshalling or unmarshalling capability. Figure A shows an overview of Castor’s data flow.
Castor is just as capable of performing Java binding with SQL tables and LDAP directories as it is with Java-XML binding. However, in this article, I will only discuss Java-XML binding. To start Java-XML binding with this handy tool, point your browser to the Castor Web site, and download the latest version.
Learn more about Java-XML binding
Receive an introduction to Java-XML binding with the article “Java-XML Data Binding offers the best of both worlds.”
Use default Castor binding—no explicit mapping involved
If your application doesn’t dictate the way you use XML, you could create a simplistic XML structure that Castor can bind with Java objects. This structure is achieved without the need for providing any explicit Java-XML mapping. My example of a simplistic XML structure includes three files, Listing A, Listing B, and Listing C.
In these listings (Listing A, Listing B, and Listing C), an instance of the Student class represents the XML as a Java object. For Castor to do the mapping, all you need to do is follow standard Java Bean conventions for getter and setter methods.
Castor first parses the XML file (see Listing C), and then based on the class name provided while instantiating the unmarshaller, the call setter methods within this class are used to create a Java object containing the desired data. (This is the data that is retrieved from the XML.) In the example, for Castor to be able to create the Java Object, the setter methods names must exactly map to the names of the XML elements.
So for the element name, there must be a method setName in the Student class. However, this object needs to be explicitly cast into a Student object so you can easily work with it in your Java code.
Provide explicit mapping
In real life scenarios, it isn’t likely that you would have a choice, in regard to the structure of the XML your application receives or even the structure of the XML that your application might have to produce.
Irrespective of how strange the XML received is, you still need to be able to map it to a Java Object. So you need to provide Castor with the mapping that would enable it to decipher how you want to create your Java object or XML.
Mapping is the one aspect of Castor that can be difficult to comprehend, so give yourself some time to come to terms with the idiosyncrasies of a mapping file.
In the sample application, the TryStudent class (Listing D), on execution, unmarshalls data from Unmarshall.xml (Listing E) to create an instance of StudentOne (Listing H). The only distinction here from the previous example is the use of the UnmarshallMapping.xml. The mapping file tells Castor which node is to be mapped to and which variable and data type you expect.
Once you have the content of the XML data, you could perform some processing on it. For example, some calculations could have been performed using MarshallMapping.xml to marshal the new Java Object into a new XML file in a completely distinct structure from the one in which you received the content. In this example, you could easily change the names used or create attributes instead of elements to hold the content.
Major advantages of this mapping-based binding is that the code remains very flexible, and any changes to XML that might come up can easily be absorbed without much tweaking in the actual Java code.
Castor also provides a properties file where you could easily configure things, such as whether Castor should indent, validate, or debug. Download it now and get started using this handy tool.