[jboss-as7-dev] Logging Subsystem Changes

[Andrig Miller]

----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: jboss-as7-dev at 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.
> 

That would be much preferable over losing the boot.log altogether.  To me, losing the boot.log would be very bad for support and for customers.  I know when I was a customer we used it quite a bit, just to verify the setup of particular AS instances.  Also, what's typical in any production environment, not just cloud, is you won't have a CONSOLE to capture any output anyway.

Andy

> > 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
> >>>
> >
> 
> 
> --
> Brian Stansberry
> Principal Software Engineer
> 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
>