Log4Ant has a few ways for you to tell it the target logger for a particular message or for a group of related messages. For this overview, we assume you want to configure where explicitly emitted messages should go; as in, to which logger would my messages sent using <emit:show> and <emit:checkpoint> go. Because the discussed parameters are used by all Log4Ant components in the same way, once you understand how these standard configuration parameters work in one particular case, it’s easy to apply that knowledge to other situations.

The logger “names” you specify to Log4Ant are actually dot-separated logger name paths that reflect a hierarchy of Loggers (with a capital “L”). Recall that a Logger identifies a logging system object that knows how to handle your incoming log requests according to configuration that you have associated with it and optionally its parent Loggers including the always-present root (or no-name) Logger. When you specify a path with more than one logger’s name, the Log4Ant system will locate (or create) all of the parent Loggers as needed to perform the requested operation. So the logger name “MyApp.Deployments” can actually involve up to three Loggers: the root Logger, the “MyApp” Logger, and finally the “MyApp.Deployments” Logger.

The way you explicitly identify a logger name in Log4Ant is with the ‘to’ parameter. This parameter takes a dot-separated string which is the logger name path. Either you can set this parameter directly on the Log4Ant component (as with <emit:show>) or on the Log4Ant configuration object used by the component. The example snippet below explicitly sends a message to the “Deployments” Logger.

<emit:show messageid="LF.deploy.started" to="Deployments"/>

This next example shows how you might define a configuration “deploy.log.conf” that will send messages to the nested Logger “Deployments” that resides under a “MyApp” parent. Any Log4Ant component that uses this configuration will send messages to this nested Logger.

<emit:configuration id="deploy.log.conf"
   to="MyApp.Deployments"
   .../>
 
[1- Anything nested within overlay will use it]
<emit:overlay with="deploy.log.conf">
  <emit:checkpoint messageid="LF.deploy.started"/>
  ...
</emit:overlay>
 
[2- Anything nested within capture will use it]
<emit:capturelogs with="deploy.log.conf">
  <echo message="Deployment has started"/>
  ...
</emit:capturelogs>
 
[3- Even a standalone show can use it]
<emit:show messageid="LF.deploy.instance"
    with="deploy.log.conf" arg0="@{instance}".../>

Sometimes it is convenient to use a logger name that is not fixed or that is not known ahead of time; for instance, say for your nightly test executions you want all output messages anchored according to the current date and time like “<Date>.MyApp”? Or say you want to leverage the previous statement “associated with…its parent Loggers” because you don’t want to setup each and every Logger; instead you want setup strategic parent nodes and let child Loggers inherit the settings.

Log4Ant lets you define dynamic logger names and links to other logger names using the special ‘wrt’ (with-respect-to) parameter. For example, the next snippet defines a configuration that is anchored by a Logger named after the time the script begins to execute.

<emit:configuration id="app.log.conf"
  wrt="longdate" to="MyApp"
  echo="no" .../>

Given the above, lets say now you want to configure two sub-Loggers of “<Date>.MyApp” differently. If you want to inherit the other settings of the MyApp definition, you would use the ‘defaults’, ‘wrt’, and ‘to’ parameters in your new sub-Logger configurations like so:

<emit:configuration id="ptests.log.conf"
  defaults="app.log.conf"
  wrt="default" to="ProgrammerTests".../>
 
<emit:configuration id="itests.log.conf"
  defaults="app.log.conf"
  wrt="default" to="IntegrationTests".../>

In our examples, we explicitly defined the default (or fall-back) configuration for each of our sub-Loggers; if you’re going to have more than a couple distinct nested Loggers it would be more convenient to install the “app.log.conf” as the global Log4Ant default configuration as shown below or to setup a <presetdef> with parameters pre-filled with the default reference.

<emit:configuration id="app.log.conf"
  wrt="longdate" to="MyApp"
  isdefault="yes".../>  [Install as default to ease use]
...
<emit:configuration id="build.log.conf"
  wrt="default" to="Build".../>
 
<emit:configuration id="ptests.log.conf"
  wrt="default" to="ProgrammerTests".../>
 
<emit:configuration id="deploy.log.conf"
  wrt="default" to="Deployments".../>
 
<emit:configuration id="ctests.log.conf"
  wrt="default" to="CustomerTests".../>

If you don’t care about the other configuration details and just want to make sure your sub-Logger is rooted to the correct parent Logger, you could drop the ‘defaults’ and use just the ‘wrt’ to refer back to the parent configuration’s own ‘to’ parameter like so:

<emit:configuration id="ptests.log.conf"
  wrt="app.log.conf" to="ProgrammerTests"
  level="trace"/>
...

The important point to remember is that ‘wrt’ acts as an adjustment to the ‘to’ parameter and will always affect the final logger name depending on the value you prescribe. To learn more about the set of possible values for the ‘wrt’ parameter, read the Log4Ant User Guide.

• How do I get properties and other information in messages?
• Complete Log4Ant User Guide