[jboss-as7-dev] Logging Subsystem Changes

[Stuart Douglas]

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.

Assuming of course that the first boot succeeds :-) Trying to figure out 
why your new install won't boot sounds like it might be a problem.

>
> 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.

So this means that after the first start the logging.properties will be 
modified? Shouldn't we be trying to ship a logging.properties that 
corresponds to the default standalone.xml settings? Or does the lack of 
expressions mean that we now have to write absolute paths to this file?

Stuart

>
> 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
>>>
>