Skip to end of metadata
Go to start of metadata


Overview

The overall server logging configuration is represented by the logging subsystem. It consists of four notable parts: handler configurations, logger, the root logger declarations (aka log categories) and logging profiles. Each logger does reference a handler (or set of handlers). Each handler declares the log format and output:


Attributes

The root resource contains two notable attributes add-logging-api-dependencies and use-deployment-logging-config.

add-logging-api-dependencies

The add-logging-api-dependencies controls whether or not the container adds implicit logging API dependencies to your deployments. If set to true, the default, all the implicit logging API dependencies are added. If set to false the dependencies are not added to your deployments.

use-deployment-logging-config

The use-deployment-logging-config controls whether or not your deployment is scanned for per-deployment logging. If set to true, the default, per-deployment logging is enabled. Set to false to disable this feature.

Per-deployment Logging

Per-deployment logging allows you to add a logging configuration file to your deployment and have the logging for that deployment configured according to the configuration file. In an EAR the configuration should be in the META-INF directory. In a WAR or JAR deployment the configuration file can be in either the META-INF or WEB-INF/classes directories.

The following configuration files are allowed:

  • logging.properties
  • jboss-logging.properties
  • log4j.properties
  • log4j.xml
  • jboss-log4j.xml

You can also disable this functionality by changing the use-deployment-logging-config attribute to false.


Logging Profiles

Logging profiles are like additional logging subsystems. Each logging profile constists of three of the four notable parts listed above: handler configurations, logger and the root logger declarations.

You can assign a logging profile to a deployment via the deployments manifest. Add a Logging-Profile entry to the MANIFEST.MF file with a value of the logging profile id. For example a logging profile defined on /subsystem=logging/logging-profile=ejbs the MANIFEST.MF would look like:

A logging profile can be assigned to any number of deployments. Using a logging profile also allows for runtime changes to the configuration. This is an advantage over the per-deployment logging configuration as the redeploy is not required for logging changes to take affect.


Default Log File Locations

Managed Domain

In a managed domain two types of log files do exist: Controller and server logs. The controller components govern the domain as whole. It's their responsibility to start/stop server instances and execute managed operations throughout the domain. Server logs contain the logging information for a particular server instance. They are co-located with the host the server is running on.

For the sake of simplicity we look at the default setup for managed domain. In this case, both the domain controller components and the servers are located on the same host:

Process Log File
Host Controller ./domain/log/host-controller.log
Process Controller ./domain/log/process-controller.log
"Server One" ./domain/servers/server-one/log/server.log
"Server Two" ./domain/servers/server-two/log/server.log
"Server Three" ./domain/servers/server-three/log/server.log

Standalone Server

The default log files for a standalone server can be found in the log subdirectory of the distribution:

Process Log File
Server ./standalone/log/server.log


Filter Expressions

Filter Type Expression Description Parameter(s) Examples
accept accept Accepts all log messages. None accept
deny deny enies all log messages. None deny
not not(filterExpression) Accepts a filter as an argument and inverts the returned value. The expression takes a single filter for it's argument. not(match("JBAS"))
all all(filterExpressions) A filter consisting of several filters in a chain. If any filter find the log message to be unloggable, the message will not be logged and subsequent filters will not be checked. The expression takes a comma delimited list of filters for it's argument. all(match("JBAS"), match("WELD"))
any any(filterExpressions) A filter consisting of several filters in a chain. If any filter fins the log message to be loggable, the message will be logged and the subsequent filters will not be checked. The expression takes a comma delimited list of filters for it's argument. any(match("JBAS"), match("WELD"))
levelChange levelChange(level) A filter which modifies the log record with a new level. The expression takes a single string based level for it's argument. levelChange(WARN)
levels levels(levels) A filter which includes log messages with a level that is listed in the list of levels. The expression takes a comma delimited list of string based levels for it's argument. levels(DEBUG, INFO, WARN, ERROR)
levelRange levelRange([minLevel,maxLevel]) A filter which logs records that are within the level range. The filter expression uses a "[" to indicate a minimum inclusive level and a "]" to indicate a maximum inclusive level. Otherwise use "(" or ")" respectively indicate exclusive. The first argument for the expression is the minimum level allowed, the second argument is the maximum level allowed.
  • minimum level must be greater than DEBUG and the maximum level must be less than to ERROR

    levelRange(DEBUG, ERROR)

  • minimum level must be greater than or equal to DEBUG and the maximum level must be less than ERROR

    levelRange[DEBUG, ERROR)

  • minimum level must be greater than or equal to INFO and the maximum level must be less than or equal to ERROR

    levelRange[INFO, ERROR]
match match("pattern") A regular-expression based filter. The raw unformatted message is used against the pattern. The expression takes a regular expression for it's argument. match("JBAS\d+")
substitute substitute("pattern", "replacement value") A filter which replaces the first match to the pattern with the replacement value. The first argument for the expression is the pattern the second argument is the replacement text. substitute("JBAS", "EAP")
substituteAll substituteAll("pattern", "replacement value") A filter which replaces all matches of the pattern with the replacement value. The first argument for the expression is the pattern the second argument is the replacement text. substituteAll("JBAS", "EAP")

List Log Files and Reading Log Files

Log files can be listed and viewed via management operations. The log files allowed to be listed and/or viewed is intentionally limited to files that exist in the jboss.server.log.dir and are associated with a known file handler. Known file handler types include file-handler, periodic-rotating-file-handler and size-rotating-file-handler. The operations are valid in both standalone and domain modes.

List Log Files

The list-log-files operation is available on the root logging resource, /subsystem=logging in standalone CLI syntax. The files listed are the only files allowed to be read by the read-log-file operation.

CLI command and output

Read Log File

The read-log-file operation is available on the root logging resource, /subsystem=logging in standalone CLI syntax. Only files available in the list-log-files operation are allowed to be read. This operation has one required parameters and 4 additional parameters.

Name Description
name (required) the name of the log file to be read
encoding the encoding the file should be read in
lines the number of lines from the file. A value of -1 indicates all lines should be read.
skip the number of lines to skip before reading.
tail true to read from the end of the file up or false to read top down.
CLI command and output

FAQ

Why is there a logging.properties file?

You may have noticed that there is a logging.properties file in the configuration directory. This logging configuration is used when the server boots up until the logging subsystem kicks in. If the logging subsystem is not included in your configuration, then this would act as the logging configuration for the entire server.

The logging.properties file is overwritten at boot and with each change to the logging subsystem. Any changes made to the file are not persisted. Any changes made to the XML configuration or via management operations will be persisted to the logging.properties file and used on the next boot.
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Mar 15, 2012

    It would be useful to have a section which explains the role that

    /standalone/configuration/logging.properties

    has and whether it overrides the standalone.xml logging configuration.

    The standalone.bat file includes the system property

    -Dlogging.configuration=....../standalone/configuration/logging.properties

    which suggests it does play a role?

    1. May 30, 2012

      Hello Peter

      The answer is in this same page: Why is there a logging.properties file?

  2. Mar 09, 2013

    Hi

    Can i use logback db appender as a custom -handler..?

    1. Mar 10, 2013

      The forums are really a better place to ask questions like this, https://community.jboss.org/en/jbossas7. That said, no you cannot use logback appenders, but you can use log4j appenders as a custom-handler.

  3. Sep 26, 2013

    Just thought I'd mention that for periodic-rotating-file-handler, append is no longer an attribute, but a tag. On WF8 Alpha4 I get this error: Message: JBAS014788: Unexpected attribute 'append' encountered.

    Replace the attribute with a tag like this:

  4. Jan 12, 2015

    What is the alternative to -Dorg.jboss.logging.Log4jService.catchSystemOut=false in WildFly-8? This system property was working in AS-5.

    My webapp is setup with Log4j with output to FILE and CONSOLE. The FILE logging is working as expected. The CONSOLE logging has following problems which I expect to avoid with disabling WF handling stdout:

    • Log4j console output is formatted with WF [stdout]
    • The same behavior observed in WF server.log file

    The example below with 2 console lines generated by Log4j with red content added by WF in a console and in a server.log:

    15:31:44,141 INFO  [stdout] (MSC service thread 1-3) 2015-01-12 15:31:44,141 org.hibernate.type.BasicTypeRegistry.register(BasicTypeRegistry.java:150)
    <extra empty line>
    15:31:44,141 INFO  [stdout] (MSC service thread 1-3)   - INFO - Type registration . . .
    <extra empty line>
    1. Jan 14, 2015

      There is no replacement property. STDOUT and STDERR will always be wrapped. I'd advise against using the ConsoleAppender too. It could create deadlocks since System.out is wrapped.

      1. Jan 14, 2015

        This is not acceptable. How to develop in IDE, for example, in Eclipse without access to Log4j console output???

        Here are my solutions:

        Rollback WF System.out wrapping. The webapp initialization is started from listeners (before first stdout or log). Implement listener with the following code:

        @Override
        public void contextInitialized(ServletContextEvent contextEvent) {
          // Restore System.out and System.err messed up by WildFly-8
          // See http://stackoverflow.com/questions/5339499/resetting-standard-output-stream
          System.setOut(new PrintStream(new FileOutputStream(FileDescriptor.out)));
          System.setErr(new PrintStream(new FileOutputStream(FileDescriptor.err)));
        }

        Implement STDOUT logging using Log4j without dependency on WildFly-8

        See http://stackoverflow.com/questions/1200175/log4j-redirect-stdout-to-dailyrollingfileappender

        1. Jan 14, 2015

          System.out and System.error are wrapped during the deployment process. It'd be best to just exclude the logging subsystem with a jboss-deployment-structure.xml. Then neither stream would be wrapped. You'd have to include your own version of log4j, but then all log4j control is up to your app.

          1. Jan 15, 2015

            Your suggestion does not work. I already have the following exclusions to keep my webapp logging classes separate from WildFly logging system:

            <exclusions>
              <module name="org.apache.log4j"/>
              <module name="org.apache.commons.logging"/>
              <module name="org.slf4j"/>
              <module name="org.slf4j.impl"/>
            </exclusions>

            These exclusions do not prevent System.out and System.err from WildFly wrapping.
            I also tried the following exclusions to ask WidFly not to modify System.out and System.err:

              <module name="org.jboss.logging"/>
              <module name="org.jboss.logmanager"/>
              <module name="org.jboss.logmanager.log4j"/>
              <module name="org.jboss.logmanager.jul-to-slf4j-stub"/>

            Non of them (or all of them together) prevent System.out and System.err from WildFly wrapping. 

            AFAIK, exclusions are required to resolve class loading collisions. WildFly is wrapping  System.out and System.err on JVM level. 

            1. Jan 15, 2015

              You need to exclude the subsystem not the modules.

              The wrapping of System.out and System.error happens during a deployment processor which is part of the logging subsystem.

              1. Jan 16, 2015

                I tried... This exclusion completely cuts off logging subsystem from the webapp but does not prevent System.out and System.error wrapping.

  5. Jan 15, 2015

    Log4J has some great documentation on how to configuration the logging pattern.  http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html 

    However, I cannot find similar documentation for the Wildfly pattern logger, and while the patterns seem similar to Log4j there are differences.  For example: https://developer.jboss.org/thread/202973

    Where should I be looking for this documentation?

    1. Jan 15, 2015

      Unfortunately it's not really documented at this point. It's on my long TODO list though It's essentially the same as log4j though with only a few minor differences. The %xx.xxc stuff should work now I believe.

  6. Apr 24, 2015

    So does this mean I can add an option "<maxBackupIndex value="30"/>" to the periodic-rotating-file-handler and this has the effect that files older than 30 days are deleted? EDIT: It doesn't look as if that option made its way into the logging.properties 

    1. Apr 24, 2015

      It's not an option. There's no good way to determine which files should be deleted from the log manager.