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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev