Labels

.net (1) *nix (1) administration (1) Android (2) Axis2 (2) best practice (5) big-data (1) business-analysis (1) code re-use (1) continuous-integration (1) Cordova-PhoneGap (1) database (2) defect (1) design (3) Eclipse (7) education (1) groovy (2) https (2) Hudson (4) Java (1) JAX-RS (2) Jersey (3) Jetty (1) localization (1) m2eclipse (2) MapForce (1) Maven (12) MySQL (1) Nexus (4) notes (4) OO (1) Oracle (4) performance (1) Perl (1) PL/SQL (1) podcast (1) PostgreSQL (1) requirement (1) scripting (1) serialization (1) shell (1) SoapUI (1) SQL (1) SSH (2) stored procedure (1) STS (2) Subclipse (1) Subversion (3) TOAD (3) Tomcat (4) UML (2) unit-testing (2) WAMP (1) WAS (3) Windows (3) WP8 (2) WTP (2) XML (4) XSLT (1)

Tuesday, July 19, 2011

Configuration objects read from/saved to files

For Spring-enabled applications, Spring has a rich configuration scheme, and objects can be fully configured and wired together based on the directives specified.

Alternatively, one can consider defining the application configuration by code, serializing the configuration objects to file as a starting point, and then, as needed, editing the configuration in file format.  When the application starts up, it will read in the configuration, de-serialize it back into object form and the application can work with the configuration.

Not unexpectedly, Spring has a way to set up marshallers/unmarshallers for your application so that it is opaque to the application which XML serialization library it is using.  This makes it easy to swap out for a different library.  I tried three different libraries with Spring and these are my findings:

Library PROS CONS
JAXB "The standard for Java"?
  • Require jaxb.index file in package's folder
  • Need to annotate class with @XmlRootElement
  • Have to have no-arg constructors even if it is against design practices
  • Doesn't work with Interfaces and cannot de-serialize a class extending from an abstract class
Castor
Popular?
Serializes well but on deserializing, get an error of
org.springframework.oxm.castor.CastorUnmarshallingFailureException: Castor unmarshalling exception: The class for the root element 'anonymize-settings' could not be found.; nested exception is org.exolab.castor.xml.MarshalException: The class for the root element 'anonymize-settings' could not be found.

For whatever reason, Castor doesn't add the xsi:type attribute on the root element when it serializes. 
XStream
  • Actually works
  • Codebase doesn't have to change for XStream to work with it (no design compromises)
Not popular?  But the library is so simple to use, there is absolutely no learning curve so you don't have to devote a lot of time to it