[jboss-as7-dev] Logging Subsystem Changes

[Brian Stansberry]

On 11/26/12 4:47 PM, James Perkins wrote:
> Hello All,
> There have been a few notable changes (pending changes) in the logging
> subsystem that I should probably make known to every one.
>
> The most notable is probably the way the logging.properties file is
> used. The file will be overwritten each time a change to the logging
> subsystem is made. It also writes out fully resolved values, e.g. any
> expressions like ${jboss.root.level:INFO} are not written out. This
> means that changes to expressions on the XML configuration will be not
> used until the logging subsystem kicks in.
>

We had a lot of people complaining about our overwriting the config 
files and asking that we not do that. So we've added a startup switch in 
master that disables overwriting the user-provided config. I think 
people who use that are going to want equivalent behavior for the 
logging.properties file.

> Not writing out expression could be an issue with paths more than
> anything. This could be an issue if you copy a configuration (from
> production to dev for example) and expect ${jboss.server.log.dir} to be
> resolved. Since the full path is written out, it's likely on initial
> boot without any changes the log will be written to the production
> directory and file.
>
> I can't think of a solid way to fix this issue. Writing out the
> expression to the logging.properties file wouldn't always work as the
> system property may not be set yet.
>
> There will no longer be a boot.log. On the initial boot of a fresh
> install the console is the only stream written to until the logging
> subsystem kicks in which will then write to the server.log as usual.
>

To clarify a bit, AIUI, the reason there is only console logging on 
*initial* boot is because the logging.properties we ship only has a 
CONSOLE appender. Then during that initial boot the logging subsystem 
kicks in and the server.log appender gets processed. The result is that 
gets written to logging.properties, so the *next* boot of the system 
that appender will be in logging.properties and the server.log file will 
be written to from the very beginning of boot.

> Since the host controller and process controller don't use the logging
> subsystem, the configuration is as it always has been in the
> logging.properties file of the $JBOSS_HOME/domain/configuration.
>
> Of course if you don't want to use the logging subsystem, then it can be
> disabled and the logging.properties will be the configuration used for
> logging.
>
> We've introduced logging profiles. A logging profile is like a separate
> logging subsystem, in a sense at least. All the same operations are on a
> logging profile. It can be used to define a different logging
> configuration for a deployment. They can be applied to a deployment by
> adding a Logging-Profile entry to the MANIFEST.MF for the deployment.
>
> log4j appenders can be set-up via a custom-handler. Just define the
> appenders properties as you would any other custom-handler and it will
> be wrapped in a handler. The one caveat is it requires the logging
> subsystem to be used. Since the logging.properties file is always
> written, appenders will also be written requiring the logging subsystem
> to use it's appender -> handler.
>
> There has been a PR submitted to finally allow for expressions on most
> of the attributes.
>
> Yet to have a PR submitted due to an open PR for STDIO and a new release
> of STDIO is removing the requirement to use JBoss Log Manager on a
> standalone server. This would allow a user to use log4j or logback as
> their log manager to control logging for the server if they'd prefer.
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat