You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by ce...@apache.org on 2002/10/10 22:36:22 UTC
cvs commit: jakarta-commons-sandbox/joran specification.html

ceki        2002/10/10 13:36:22

  Added:       joran    specification.html
  Log:
  First commit.
  
  Revision  Changes    Path
  1.1                  jakarta-commons-sandbox/joran/specification.html
  
  Index: specification.html
  ===================================================================
  
  <html>
  
    <head>
      <title>Ideas for the Joran project</title>
    </head>
    
    <body>
      
      <center>
        <h1>Ideas for the Joran</h1>
        Ceki G&uuml;lc&uuml;
      </center>
      
      <p>The projects takes its name from a cold north-west wind that
        occasionally but forcefully blows on the Leman lake.
      </p>
      
        
      <p>The joran project will implement a generic XML-based
      configuration tool for the Java platform. 
      </p>
  
      <h2>Introduction</h2>
  
      <p>One of the most powerful features of the Java language is
        reflection. Using reflection it is possible to configure
        software systems declaratively. For example, many important
        properfies of a EJB are be configured with an ejb.xml. The EJB
        is written in Java but many of its properties are specified
        within the ejb.xml file. Similarly, the log4j logging framework
        are specified in a configuration file which can be in
        key=properties format or in XML.
      </p>
  
      <p>The DOMConfigurator that ships with log4j can parse
        configurations files written in XML. The DOMConfigurator is
        written in Java such that each time the format of the
        configuration file changes the DOMConfigurator must be tweaked
        accordingly and the resulting code must be recompiled and
        redeployed. Just as importantly the code of the DOMConfigurator
        consists of a bunch of loops on children of elements with many
        interspread if/else statemets. One can't help but notice that
        the code reeks of redundancy.
      </p>
  
      <p>The <a
        href="http://jakarta.apache.org/commons/digester.html">digester
        project</a> has shown that it is possible to parse XML files
        using rules consisting of a patterns and actions. While the XML
        file is being parsed whenever a pattern is matched the
        corresponding action is invoked. Action classes are usually
        quite small and specialized classes. Consequently, they are easy
        to understand and maintain. 
      </p>
  
      <p>I find the the commons-digester terminology somewhat
       confusing. In commons-digester a rule can be seen as consisting
       of a pattern and a rule, as shown by the <a
       href="http://jakarta.apache.org/commons/digester/api/org/apache/commons/digester/Digester.html#addRule(java.lang.String,%20org.apache.commons.digester.Rule)">Digester.addRule(java.lang.String
       pattern, Rule rule)</a> method. In commons-joran, a rule consists
       of a pattern and an action.
      </p>
  
      <p>Quite remarkably, one can handle very complex situations by
        using simple patterns, that is exact matches and wilcard
        matches. For example, the pattern a/b will match a "&lt;b>"
        element nested with a "&lt;a>" element but not a "&lt;c>"
        element even if nested within "&lt;b>". It is also possible to
        match a particular XML element, regardless of its nesting, by
        using the "*" wildcard character. For example, an element
        matching pattern of "*/a" will match an &lt;a> element at any
        nesting position within the document. Other types of patterns,
        for example, "a/*" were not supported by the earlier versions of
        commons-digester.
      </p>
  
      
  
    </body> 
  </html>
  
  
  

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>