[jboss-as7-dev] Logging Subsystem Changes

[Misty Stanley-Jones]

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 ☏: + 61 7 3514 8105

On Nov 27, 2012, at 9:53 AM, Brian Stansberry <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
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20121127/01811a8b/attachment.html