[jboss-as7-dev] Logging Subsystem Changes

[Brian Stansberry]

EAP 6.1

On 11/26/12 10:00 PM, Misty Stanley-Jones wrote:
> What is the timing for all these changes? These are some pretty major
> ones with a potential documentation impact.
>
> Misty Stanley-Jones, RHCE
> Supervisor, Engineering Content Services
> Red Hat Brisbane (GMT+10)
> ☺: misty (IRC) ✉: misty at redhat.com <mailto:misty at redhat.com>☏: +61 7
> 3514 8105
>
> On Nov 27, 2012, at 9:53 AM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>
>> 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 at lists.jboss.org <mailto: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