[jboss-as7-dev] Logging Subsystem Changes

Brian Stansberry brian.stansberry at redhat.com
Tue Nov 27 09:46:30 EST 2012


On 11/27/12 12:13 AM, Stuart Douglas wrote:
>
>
> 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?
>

Expressions should work to the extent they worked in the past. The 
parser hasn't changed -- it can handle expressions.

The problem with expressions in the file is the file is parsed very 
early in the boot, before the host/standalone.xml file is processed and 
even before org.jboss.as.server.Main processes any -D values or -P 
passed on the command line. Basically only system properties set via 
standalone.conf are visible. This has always been a usability issue with 
the boot log -- configuring it requires some black art.

The reason James isn't *writing* expressions back to logging.properties 
is because expressions that resolve properly when placed in the logging 
subsystem in standalone.xml might not resolve properly when placed in 
logging.properties. By the time the logging subsystem is processed, all 
system properties are set.

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


More information about the jboss-as7-dev mailing list