Sapia releases Confix 1.4


News: Sapia releases Confix 1.4

  1. Sapia releases Confix 1.4 (5 messages)

    Escape the DOM-tree-manipulation nightmare: transform your XML configuration files into Java objects, without touching a DOM. Confix works with JDOM, DOM4J, and plain SAX events.

    Confix features at a glance:

        * translates XML configuration files into objects;
        * uses Java's Reflection API to instantiate and initialize the objects corresponding to the configuration;
        * XML elements are converted into objects;
        * supports XML namespace definitions;
        * XML attributes are mapped to "setters";
        * automatic type conversion: XML attributes are automatically converted to the type specified by their corresponding setters (int, boolean, long, etc.)
        * implements the factory pattern: separates XML traversal from object creation - the latter is delegated to "object factories".
        * allows parts of the XML to bypass the conversion mechanism: the XML will remain as such if some objects are interested in manipulating the XML themselves;
        * flexible, interface-based XML-to-object conversion strategies, suitable to solve most configuration peculiarities.

    Warning: Confix is highly addictive; you'll develop the "Configure-Everything" syndrome.

    Confix is part of Sapia's Utils package.


    Threaded Messages (5)

  2. Sapia releases Confix 1.4[ Go to top ]

    Isn't this just using Castor (an XML-to-object binding framework) to make configuration less of a hassle? I fail to see how it is any different.

    Paolo del Mundo
  3. I was expecting that ;-) Yes it is different (otherwise I would have used Castor, or Betwixt, or XStreams in my projects).

    Confix supports various strategies to create objects from XML configuration files. For example, imagine that you have these two classes:

    public class Config {

      List params = new ArrayList();

      public Param createParam(){
        Param p = new Param();
        return p;


    public class Param{
      public void setName(String name){...}
      public void setValue(String value){}

    The corresponding XML would be:

      <param name="foo" value="bar" />

    You see, you can manage Confix to call the createXXXXX methods corresponding to
    the XML element that you have specified in you configuration.

    Furthermore, as far as attributes and elements are concerned, this would also work:


    To push things further, imagine that you want to validate the Param instances before they are assigned to their parent object (Config). For example, you want to insure that these parameters do not have a 'null' name. With confix, you could do this:

    public class Param implements ObjectCreationCallback{


      public Object onCreate() throws ConfigurationException{
        if(name == null){
          throw new ConfigurationException("'name' not specified on parameter");
        return this;


    The ObjectCreationCallback interface can also be used in the cases where a class does not have a public, empty constructor, or does not have appropriate setters. For example, imagine this:


    Which would correspond to:

    public class Config{
      public void setServerUrl( url){...}

    As you know, the URL class does not have setters... We could create an URL through a convenient callback:

    public UrlCallBack implements ObjectCreationCallback{

      private String _url;

      public void setText(String url){
        _url = url;

      public Object onCreate() throws ConfigurationException{
        ... validate here ...
          return new;

    In addition, Confix decouples object creation from the core framework by introducing object factories. An object factory creates an object, given an XML prefix, local name, and URI. This allows implementing object factories on a per-namespace basis. The consequence is that objects created by different factories can have their configuration "cohabitate" in the same XML file:


    Another neat feature: sometimes, you might want a given part of your XML as is (not transformed in to objects). For example, imagine that a Config instances expects to receive its XML content directly, to pass it to some other object (this is often the case when integrating third-party frameworks that specify their own configuration format):

    public class Config implements XMLConsumer{

      public void consume(org.sax.xml.InputSource rawXml) throws Exception{

    Given the following:


    ... The "consumed" InputSource would correspond to the XML between the <config> tags (which correspond to our Config object).

    You see, the devil is in the details; from the heigths of generalization, everything is similar.

    For more info on Confix, see you at
  4. Sapia releases Confix 1.4[ Go to top ]

    sounds a lot like commons-digester
  5. Jaxb[ Go to top ]

    I think jaxb is better than it.
  6. Well Done ![ Go to top ]


    Give the guy a break. This is a different approach from XML to object mapping.
    It introduces a clear separation of the domain object model and the configuration model.
    Typically, when you use some kind of object to XML mapping, you need to add the domain specific knowledge in the configuration mapping process.

    It is your choice to love it (I do) or to take a different approach such as Castor, JAXB and others.