Re: [jboss-as7-dev] Logging Subsystem Changes

From: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org Sent: Tuesday, November 27, 2012 7:55:17 AM Subject: Re: [jboss-as7-dev] Logging Subsystem Changes On 11/26/12 5:46 PM, 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. > > 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. > I don't think so. That information is written at DEBUG, and the boot.log appender was configured to allow DEBUG, while the console was configured to allow INFO. The server.log appender was for INFO as well. This combination allowed the JVM parameter details to be captured in the boot.log while not appearing on the console and not requiring the main server.log to append DEBUG messages. I haven't thought this through, but I suspect there is some category+appender combo that will allow us to meet the primary goal here. Basically, a boot.log that only contains a limited set of diagnostic info logged at DEBUG, while CONSOLE and server.log don't include that info.

> 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(a)redhat.com&gt; >>> To: &quot;jboss-as7-dev(a)lists.jboss.org Development" >>> <jboss-as7-dev(a)lists.jboss.org&gt; >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> > -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev