9.2 (Trace) Logging
Prev | 9. Serviceability | Next

## 9.2 (Trace) Logging

The Virgo Web Server’s (trace) logging support serves two main purposes:

- It provides global trace files that capture high-volume information regarding the Virgo Web Server’s internal events. The files are intended for use by support personnel to diagnose runtime problems.
- It provides application trace files that contain application-generated output. This includes output generated using popular logging and tracing APIs, as well as output generated by calls to `System.out` and `System.err`. These files are intended for use by application developers and system administrators.

By default, the VWS trace file is called `$SERVER_HOME/serviceability/logs/log.log`, and, again by default, the application trace files are called `$SERVER_HOME/serviceability/logs/`application_name`/log.log`, where application_name is automatically set by VWS for each application artifact installed and run (it is a combination of the artifact name and the version).

The default behaviour of these trace files is that, once `log.log` reaches a 10Mb limit, it rolls into a series of files named `log_`i`.log` where i ranges from 1 to 4, and logging continues in a new `log.log` file.

Entries in trace files are by default of the form <timestamp> <thread-name> <source> <level> <entry-text>. For example:

    [2008-05-15 09:09:46.940] server-dm-2 org.apache.coyote.http11.Http11Protocol I Initializing Coyote HTTP/1.1 on http-48080

although this format is completely determined by the Logback configuration file `serviceability.xml`.

### Application Output

Virgo Web Server provides advanced support for capturing and tracing application-generated output by automatically separating trace output on a per-application basis and will also capture any `System.out` and `System.err` output.

#### Per-application trace

Virgo Web Server uses SLF4J interfaces to Logback, and the root logger (by default) captures all logging output and appends it to the application-specific trace files as described above. To modify this, define application-specific loggers in the `serviceability.xml` file in the normal way.

#### System.out and System.err

`System.out` and `System.err` output from applications is, by default, captured in the application’s trace file. This happens because the output streams are intercepted and written to the loggers named `System.out` and `System.err` respectively. Since there are no explicit loggers defined with these names in the `serviceability.xml` file, this output is logged by the root logger (which captures `INFO` level and above).

The capture of `System.out` and `System.err` output is configured in the `config/org.eclipse.virgo.medic.properties` file by the `log.wrapSysOut` and `log.wrapSysErr` properties. By default the properties have a value of `true` and capture is enabled. Capture can be disabled by configuring the properties with a value of `false`.

The trace entries for `System.out` and `System.err` output are of the form:

    [2008-05-16 09:28:45.874] server-tomcat-thread-1 System.out Hello world!
    [2008-05-16 09:28:45.874] server-tomcat-thread-1 System.err Hello world!

The third column indicates where the output came from (`System.out` or `System.err`).

To over-ride this behaviour, simply define explicit loggers named `System.out` and/or `System.err` in the configuration file to send this output to an appender of your choice. Be aware that all applications’ output streams will be caught by these loggers, and that a sifting appender might be useful to separate them.

Prev | Up | Next
9. Serviceability | Home | 9.3 Service Dumps