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

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.

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&quot;&lt;jperkins(a)redhat.com&gt; >> To: &quot;jboss-as7-dev(a)lists.jboss.org Development&quot;&lt;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 >>

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&quot;&lt;jperkins(a)redhat.com&gt; >>> To: &quot;jboss-as7-dev(a)lists.jboss.org Development&quot;&lt;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 >>> > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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(a)redhat.com&gt; > To: "Stuart Douglas" <stuart.w.douglas(a)gmail.com&gt; > Cc: "Andrig Miller" <anmiller(a)redhat.com&gt;, &quot;jboss-as7-dev(a)lists.jboss.org Development" > <jboss-as7-dev(a)lists.jboss.org&gt; > Sent: Tuesday, November 27, 2012 9:31:40 AM > Subject: Re: [jboss-as7-dev] Logging Subsystem Changes > > > On 11/26/2012 10:13 PM, 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? > I'm trying to remember what the issue was with keeping the file > handler > in the initial properties. It was almost a year ago I was working on > this. I almost think it may have been something with the > jboss.server.log.dir system property. Since a while ago we changed > that > to get resolved in the scripts, it might not really be an issue at > all. > I'll test it today and see if we can get that working. > > We still wouldn't end up with a separate boot log, but everything > would > be logged into server.log from the start. This sounds promising. We certainly won't need the boot log if we can get everything into the server log.

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

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.

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

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.

What is the timing for all these changes? These are some pretty major ones with a potential documentation impact. Misty Stanley-Jones, RHCE Supervisor, Engineering Content Services Red Hat Brisbane (GMT+10) ☺: misty (IRC) ✉: misty(a)redhat.com <mailto:misty@redhat.com>☏: +61 7 3514 8105 On Nov 27, 2012, at 9:53 AM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: > On 11/26/12 4:47 PM, James Perkins wrote: >> 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. >> > > We had a lot of people complaining about our overwriting the config > files and asking that we not do that. So we've added a startup switch in > master that disables overwriting the user-provided config. I think > people who use that are going to want equivalent behavior for the > logging.properties file. > >> 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. >> > > To clarify a bit, AIUI, the reason there is only console logging on > *initial* boot is because the logging.properties we ship only has a > CONSOLE appender. Then during that initial boot the logging subsystem > kicks in and the server.log appender gets processed. The result is that > gets written to logging.properties, so the *next* boot of the system > that appender will be in logging.properties and the server.log file will > be written to from the very beginning of boot. > >> 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. >> > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > >

A couple of things that I'm wondering about the logging.properties related changes are: 1) Until now, I don't think many users are even aware that there's a logging.properties being used and for them the logging subsystem is the sole representation of the logging configurations. I know the documentation[1] does talk about the logging.properties, but I still don't think many users are concerned/aware about it. I might not have understood the full implications of the changes yet, but it looks like we are exposing the presence of the logging.properties to the users which can have very confusing results. For example, if the logging subsystem is configured to have an appender which logs to ${foo}/bar.log then: a) During first run the user starts the server with -Dfoo=/home/run1 then the logs correctly get written out to /home/run1/bar.log b) User restarts the server, this time with -Dfoo=/home/run2 then the *initial few logs* till logging subsystem kicks in, will be written out to /home/run1/bar.log and then the rest of the logs to /home/run2/bar.log? Did I understand this correctly?

2) Why are we overwriting the logging.properties with logging subsystem configurations? Or more precisely, isn't the logging.properties and the logging subsystem configurations meant for 2 different things?Further to this, are we writing out all the information available in the logging subsystem to the logging.properties - like the various user configured appenders and even logging profiles?

[1] https://docs.jboss.org/author/display/AS71/Admin+Guide#AdminGuide-Logging -Jaikiran _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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.