[jboss-as7-dev] Logging Subsystem Changes

[Andrig Miller]

Why are we getting rid of the boot.log?

We depend on that for information from the customer in support, and I certainly have used it many times just to see that my changes like JVM parameters, etc. are what I was expecting.  Most production systems won't even have the CONSOLE to log to, so this information is just being lost.

Andy

----- Original Message -----
> From: "James Perkins" <jperkins at redhat.com>
> To: "jboss-as7-dev at lists.jboss.org Development" <jboss-as7-dev at lists.jboss.org>
> Sent: Monday, November 26, 2012 3:47:42 PM
> Subject: [jboss-as7-dev] Logging Subsystem Changes
> 
> 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.
> 
> 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.
> 
> 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.
> 
> --
> James R. Perkins
> JBoss by Red Hat
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>