Now that we've had a tour of the components, and have an idea of what sorts of configurations are possible, you may be wondering whether there's a way to retain some sort of overview of the actual XML. Dropping component instance definitions in and out of the configuration file is somewhat tedious, and certainly when editing such a large file, it's not difficult to lose sense of direction and comment out or edit the wrong section.
<jabberd:include/>
Help is at hand, in the form of the <jabberd:include/> tag.
This tag comes from the same stable as <jabberd:cmdline/> and provides the Jabber server administrator with ways to better manage the XML configuration.
The contents of a file specified with the <jabberd:include/> tag are imported (included) in the position that the <jabberd:include/> tag occupies. Depending on what the root tag in the file to be included is, the import is done in one of two ways:
root tag matches the parent tag of <jabberd:include/>
The contents of the file minus the root tag are included
root tag does not match the parent tag of <jabberd:include/>
The entire contents of the file are included
For example, if we have a section like this in the jabber.xml file:
...
<conference xmlns="jabber:config:conference">
<public/>
<vCard>
<FN>yak Chatrooms</FN>
<DESC>This is a public chatroom service.</DESC>
<URL>http://yak/chat</URL>
</vCard>
...
<jabberd:include>./rooms.xml</jabberd:include>
</conference>
...
and the content of ./rooms.xml looks like this:
<room jid="kitchen@conference.yak">
<name>The Kitchen</name>
<notice>
<join> comes to add to the broth-spoiling</join>
<leave> can't stand the heat</leave>
<rename> is now known as </rename>
</notice>
</room>
<room jid="cellar@conference.yak">
<name>The Cellar</name>
<secret>cellarsecret</secret>
</room>then these rooms will be defined to the Conferencing component as if the configuration XML had appeared directly inside of the <conference/> configuration wrapper tag.
We can put the <jabberd:include/> tag to good use and organise our configuration component instances as shown in Example 4-23.
Example 4-23. Configuration XML organised with <jabberd:include/>
<jabber> <!-- Core components --> <jabberd:include>./sessions.xml</jabberd:include> <jabberd:include>./config/standard/xdb.xml</jabberd:include> <jabberd:include>./config/standard/c2s.xml</jabberd:include> <!-- Testing --> <!-- <jabberd:include>./config/local/conference.xml</jabberd:include> <jabberd:include>./config/test/test.service.xml</jabberd:include> --> <!-- Logging --> <jabberd:include>./config/standard/elogger.xml</jabberd:include> <jabberd:include>./config/standard/rlogger.xml</jabberd:include> <!-- Internal-only server right now <jabberd:include>./config/standard/dnsrv.xml</jabberd:include> <jabberd:include>./config/standard/s2s.xml</jabberd:include> --> <!-- Misc --> <jabberd:include>./config/standard/jud.xml</jabberd:include> <!-- IO (incl. karma), PIDfile --> <jabberd:include>./config/standard/io.xml</jabberd:include> <jabberd:include>./config/standard/pidfile.xml</jabberd:include> </jabber>
The XML in Example 4-23 gives us a great overview of which components are included in our Jabber server; we have the core components providing the Session Management, Client (to Server) Connections and Data Storage services; a couple of components under test (Conferencing and a custom component we're calling 'test.service') that are currently deactivated; the Logging services in their standard configuration; the components providing facilities for connecting to other Jabber servers - Server (to Server) Connections and Hostname Resolution - are currently inactive, meaning that as configured, the Jabber server will be purely internal; there's also a local JUD defined too, and finally we have the IO and PIDfile specifications - also abstracted out into separate XML chunks.
This works well especially if there are certain parts of the configuration - for example certain component instance definitions - that don't normally change; you can see that many of the component configuration files are in a 'standard' directory, which by convention could signify that they're the same as the XML configuration as-delivered and are not likely to change.
<jabberd:cmdline/>
The <jabberd:cmdline/> tag was mentioned in Chapter 3 as a way of providing a command line hook into the configuration - values stored in the XML could be overridden by command line switches used when invoking jabberd.
The tag is used in the standard XML configuration (see Figure 4-3) to allow replacement of the hostname and spool directory:
<host><jabberd:cmdline flag="h">yak</jabberd:cmdline></host>
and
<spool><jabberd:cmdline flag='s'>./spool</jabberd:cmdline></spool>
In fact, this tag can be used in most places in the XML - so if for example you have a requirement to modify (re-specify) the error and record log files for each jabberd invocation, you can do something like this:
<log id='elogger'> <host/> <logtype/> <format>%d: [%t] (%h): %s</format> <file><jabberd:cmdline flag="e">error.log</jabberd:cmdline></file> <stderr/> </log>
and then override the value error.log with something else at invocation time:
yak:~/jabber-1.4.1$ ./jabberd/jabberd -e error_log.txt &