What is the difference between these configurations :
<Engine name="Catalina" defaultHost="localhost" debug="0">
<Logger className="org.apache.catalina.logger.FileLogger"
prefix="catalina_log." suffix=".txt"
timestamp="true"/>
<Host name="localhost" debug="0" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Context path=""
docBase="/Users/mccallister/src/gear/target/gear/"
debug="1"
reloadable="true" />
</Host>
</Engine>
and
<Call name="addWebApplication">
<Arg>/</Arg>
<Arg>/Users/mccallister/src/gear/target/gear/</Arg>
<Set name="extractWAR">false</Set>
<Set name="defaultsDescriptor">org/mortbay/jetty/servlet/webdefault.xml</Set>
<Set name="virtualHosts">
<Array type="java.lang.String">
<Item>127.0.0.1</Item>
<Item>localhost</Item>
</Array>
</Set>
</Call>
other than one is for Tomcat and one is for Jetty (I picked these because I am not involved in the development of either but use both)?
On the surface, the second one may seem a little bit less clear. Reading it and thinking you can see it is doing the same as the first, configuring options on a web application deployment. However, I think it is far more clear in important ways. You know exactly what is being configured by it.
Most of us are used to doing lookups for configuration settings. We'll provide a properties file, or xml document. This document will be parsed into some time of object based configuration metadata model at runtime. Configurable entities will be given this metadata model and will pull out the information they need. This is the example of the first xml snippet.
The second snippet, on the other hand, is not parsed into an XML metadata model or provided to anything. It specifies calls and property setters quite literally. There is no lookup going on at runtime. I'll call this active configuration for lack of some other term.
This style of configuration makes explicit what the configuration properties actually do, and what they are provided to. There is no "yeah, this property makes no sense, but if we move it all hell breaks loose because it is looked up by umpteen things" configuration issues. It allows for much more flexible configuration options, nanocontainer being a great example of this (you could probably do the same in spring, but they seem to have more closely welded the XML configuration to the bean factory).
Active configuration, in comparison to passive configuration, isn't a matter of the configuration file format, but what is done with it. A perl script which is configured via setting some variables which are then read in lots of places is just as passive as passing around a Properties instance. The key is that the configuration file is processed and used to build the application, then can be thrown away. It contains declarative instructions for what to do, not properties accessed by the running application. The recent popularity of groovy and beanshell based configuration makes this easier to do -- simply because then the configuration really is interpreted. This is, by no means, the only way however.
Nagios and the Apache Web Server both use this style of configuration (I say this with some risk as it is based on configuring and using them, not looking through the source code to see how the configs are used ;-), and both define domain specific little languages for writing the config files. I doubt we'll see many ANTLR based (analagous to lex/yacc based) application-specific configuration languages appearing -- there is no need for them usually. It is trivial to use a DOM tree as an AST and write an interpreting visitor to traverse it, or to skip the interpreter step and simply use a groovy/beanshell/jython script with bootstrap components populated into the execution context.
Many applications use a combination of active and passive configuration, Cocoon comes to mind as an excellent example (while trying hard to lean towards active configuration), but I thoroughly believe that when you need to make the choice, active configuration should be preferred.