It looks like I should have added more details on why we're persisting the logging.properties file now :-)

The logging.properties file is used when JBoss Modules finds JBoss Log Manager and loads it up. This is how logging is configured until the logging subsystem kicks in. Then the context switches to using the configuration in the XML file when the logging subsystem is processed. This is done as early as it can be done, but clearly can't happen immediately which is why we have the need for an additional logging configuration file (logging.properties) .

What used to happen is when it switched from the boot configuration to the XML configuration using services, there was a brief time when log statements could be lost in the switch. By using a new configuration manager in JBoss Log Manager the switch between the two is much more seamless. No new log context is created and any additional configuration is just added to the original context. The configuration manager in the JBoss Log Manager writes the logging.properties file with the configuration it has. So if no changes were made in the XML, then the next time the server boots nothing will be changed when the logging subsystem boots.

From my personal perspective I do think it would be great to write properties back to the logging.properties file, but the log manager does not support that. It would be nice it would write out something like ${jboss.server.log.dir:/path/to/previous/log/dir}, but it only writes out the resolved values.

I did create a JIRA[1] to add back a file handler back to the initial logging.properties file. I can't exactly recall the reason I removed it, but if memory serves it had something to do with directory resolution and I think it's been changed anyway.

[1] https://issues.jboss.org/browse/AS7-6045

On 11/26/2012 02: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.

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.



-- 
James R. Perkins
JBoss by Red Hat