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.
writebacks...
I've been thinking about the same subject myself. However, I still can't get a handle on which one is better. Any thoughts on why you think active configuration should be preferred? Carlos
Active Configuration
Less mystery about what it is doing. The idea is to make dependencies explicit (and reduce dependencies), and this includes configuration dependencies. When you have lookup-based configuration, anything can look it up and use it if it makes sense. You never know this, particularly on a large project with a medium-sized or larger team (scary that I think of a team of 5-7 people as medium sized now). The benefits are the same as for dependency injection instead of service lookup, even more so as configuration is generally untyped, unlike components.
use passive
Maybe for a developer something like this jetty like configuration might make more sense. But you also have to think about the system admins. They are no developers. So reading a jetty like configuration is much less descriptive. Many developers unfortunately do these kind of mistakes. I am no sys-admin but I have gone through endless discussions and actually understand them. Oh, and I personally hate the jetty configuration. It just looks like your coding java in XML.
Active Configuration
I *am* a sysadmin, and I still believe what I am saying. The tomcat config is no more clear to a non-programmer than the jetty one -- both basically require having sample and/or doc open next to them in order to modify unless you have learned it. The jetty one does read like coding in XML, it isn't gorgeous, but it is easy to figure out what it is doing.
Active Configuration
You're aware, I presume, that Tomcat really does do "active" configuration in the sense that you are describing? The server.xml file is basically a script of object creation and parameter setter calls to be made ... the file itself is thrown away after parsing. There is still a readability difference, because the actual calls are implicit (i.e. up to whatever the parse event handlers want to do) instead of explicit. But that's a stye difference, not a functional one.
SmartFrog -we use javacc :)
Brian, you should have a play with the deploy system 'Smartfrog', url above. Its declarative, though not (currently) XML. Turns out to be hard to declare this in a human writeable XML. One of the components will configure and run jetty instances for you.
What's the difference?
My initial thought was what you meant between the two styles was that one was declarative and the other was imperative. However, I get the impression that it is more along the lines of data as configuration versus direct interpretation. Unfortunately, I don't see the difference! Can we think of the former as a push-based versus pull based? In this case the former has no idea who depends on it, while the latter does. The former is lazily evaluated, the later is eagerly evaluated. In summary, passive implies declarative, data-driven, event-driven, lazily evaluated versus imperative, control-driven, eagerly evaluated. The passive approach actually is clearly better, that's because it supports composability better. The issue you raise however is more about traceability. If I have a failure in code that is driven by configuration, then I should be able to trace back to that configuration. By linking configuration with control code you have the opinion that it improves traceability. Let me know if what I just wrote makes any sense! Carlos
Re: Craig
I wasn't aware, but I am not surprised as I think about it =) My apologies to tomcat for using the config as an example of something it isn't!
comment...