[jboss-as7-dev] Logging Subsystem Changes

[Aleksandar Kostadinov]

Stuart Douglas wrote, On 27.11.2012 08:13 (EEST):
>
>
> 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.

right, in some cloud deployments there could be only *one* boot of the 
AS server

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

+1 that would be much more helpful IMO

> 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