This is still a work in progress. Please feel free to edit any mistakes you find
.
Loggers are used to log messages. A logger is defined by a category generally consisting of a package name or a class name.
A logger is the first step to determining if a messages should be logged or not. If a logger is defined with a level, the level of the message must be greater than the level defined on the logger. The filter is then checked next and the rules of the filter will determine whether or not the messages is said to be loggable.
A logger resource uses the path subsystem=logging/logger=$category where $category is the category of the logger. For example a logger named org.wildfly.example would have a resource path of subsystem=logging/logger=org.wildfly.example.
A logger has 4 writeable attributes:
You may notice that the category and filter attributes are missing. While filter is writable it may be deprecated and removed in the future. Both attributes are still on the resource for legacy reasons.
The filter-spec attribute is an expression based string to define filters for the logger.
Filters on loggers are not inherited.
Check out Logging Configuration#FilterExpressions for more information on expressions and some examples
The handlers attribute is a list of handler names that should be attached to the logger. If the use-parent-handlers attribute is set to true and the log messages is determined to be loggable, parent loggers will continue to be processed.
The level attribute allows the minimum level to allow messages to be logged at for the logger.
The use-parent-handlers attribute is a boolean attribute to determine whether or not parent loggers should also process the log message.
The root-logger is similar to a Logger Resource only it has no category and it's name is must be ROOT.
A logger hierarchy is defined by its category. The category is a . (dot) delimited string generally consisting of the package name or a class name. For example the logger org.wildfly is the parent logger of org.wildfly.example.