[jboss-as7-dev] Logging Subsystem Changes

[Brian Stansberry]

On 11/26/12 5:46 PM, James Perkins wrote:
> Mainly because the logging.properties is overwritten so it would only be
> there on the very first boot. After that everything is written to the
> server.log. Also resolving determining the path was an issue IIRC.
>
> Note too this is only on the very first boot and a clean install. On the
> next boot the JVM parameters and what not will be written out to the
> server.log file.
>

I don't think so. That information is written at DEBUG, and the boot.log 
appender was configured to allow DEBUG, while the console was configured 
to allow INFO. The server.log appender was for INFO as well.

This combination allowed the JVM parameter details to be captured in the 
boot.log while not appearing on the console and not requiring the main 
server.log to append DEBUG messages.

I haven't thought this through, but I suspect there is some 
category+appender combo that will allow us to meet the primary goal 
here. Basically, a boot.log that only contains a limited set of 
diagnostic info logged at DEBUG, while CONSOLE and server.log don't 
include that info.

> On 11/26/2012 03:38 PM, Andrig Miller wrote:
>> 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
>>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat