Logging Subsystem Changes

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Logging Subsystem Changes

James Perkins
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Andrig Miller
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" <[hidden email]>
> To: "[hidden email] Development" <[hidden email]>
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

James Perkins
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" <[hidden email]>
>> To: "[hidden email] Development" <[hidden email]>
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>

--
James R. Perkins
JBoss by Red Hat

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Brian Stansberry
In reply to this post by James Perkins
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Misty Stanley-Jones
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) ✉: [hidden email] ☏: + 61 7 3514 8105

On Nov 27, 2012, at 9:53 AM, Brian Stansberry <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Stuart Douglas
In reply to this post by James Perkins


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"<[hidden email]>
>>> To: "[hidden email] Development"<[hidden email]>
>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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"<[hidden email]>
>>>> To: "[hidden email] Development"<[hidden email]>
>>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Brian Stansberry
In reply to this post by Misty Stanley-Jones
EAP 6.1

On 11/26/12 10:00 PM, Misty Stanley-Jones wrote:

> 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) ✉: [hidden email] <mailto:[hidden email]>☏: +61 7
> 3514 8105
>
> On Nov 27, 2012, at 9:53 AM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> 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
>> [hidden email] <mailto:[hidden email]>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Brian Stansberry
In reply to this post by Stuart Douglas
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"<[hidden email]>
>>>> To: "[hidden email] Development"<[hidden email]>
>>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Brian Stansberry
In reply to this post by James Perkins
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" <[hidden email]>
>>> To: "[hidden email] Development" <[hidden email]>
>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Jaikiran Pai
In reply to this post by Brian Stansberry
On Tuesday 27 November 2012 05:23 AM, Brian Stansberry wrote:

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

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Andrig Miller
In reply to this post by Brian Stansberry


----- Original Message -----

> From: "Brian Stansberry" <[hidden email]>
> To: [hidden email]
> 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" <[hidden email]>
> >>> To: "[hidden email] Development"
> >>> <[hidden email]>
> >>> 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
> >>> [hidden email]
> >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>>
> >
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

David Lloyd-2
In reply to this post by James Perkins
So there are some valid problems raised here.  To give some background,
the problem that is being addressed is that changes to logging
configuration are non-atomic, basically meaning that it is common to get
duplicate or missing log messages when switching between log files; also
having two log files is kind of silly.

The perfect solution would have the following characteristics:

1) Only one log file from startup to shutdown
2) Only one place to configure logging (i.e. the logging subsystem)
3) Logging changes are atomic

This solution exhibits #1 & #2 (but only if the logging config or the
server environment hasn't changed significantly between shutdown and
startup) but not #3 (still impossible with the current code base).  The
existing code does not meet any of these three characteristics.

--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Aleksandar Kostadinov
In reply to this post by Brian Stansberry
Brian Stansberry wrote, On 27.11.2012 16:46 (EEST):

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

I think the point here was (at least my point) that the information from
first boot is lost for automatic deployments. Can't logging.properties
match default logging subsystem configuration so information from first
boot is put somewhere (be it boot.log or server.log)?
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

James Perkins
In reply to this post by Stuart Douglas

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.

>
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Andrig Miller


----- Original Message -----

> From: "James Perkins" <[hidden email]>
> To: "Stuart Douglas" <[hidden email]>
> Cc: "Andrig Miller" <[hidden email]>, "[hidden email] Development"
> <[hidden email]>
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

James Perkins
In reply to this post by Jaikiran Pai

On 11/27/2012 07:11 AM, Jaikiran Pai wrote:

> 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?
That is correct. I'm not sure how often that does happen, but it will be
an issue.
>
> 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?
We're overriding to so the switch between the logging.properties
configuration and the logging subsystem is much more seamless. I
actually think it *could* make the user care less about the
logging.properties file.

No, logging profiles only work when the logging subsystem is running.
They're only used for deployments, which are started after the logging
subsystem.
>
> [1]
> https://docs.jboss.org/author/display/AS71/Admin+Guide#AdminGuide-Logging
>
> -Jaikiran
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--
James R. Perkins
JBoss by Red Hat

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

Brian Stansberry
In reply to this post by Andrig Miller
On 11/27/12 10:44 AM, Andrig Miller wrote:

>
>
> ----- Original Message -----
>> From: "James Perkins" <[hidden email]>
>> To: "Stuart Douglas" <[hidden email]>
>> Cc: "Andrig Miller" <[hidden email]>, "[hidden email] Development"
>> <[hidden email]>
>> 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.
>

The trick is the one bit of value the boot.log added was letting through
all the DEBUG info in category org.jboss.as.config while not having the
console show it and not having the main server.log log DEBUG.

> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

James Perkins
In reply to this post by James Perkins
It looks like I should have added more details on why we're persisting the logging.properties file now :-)

The logging.properties file is used when JBoss Modules finds JBoss Log Manager and loads it up. This is how logging is configured until the logging subsystem kicks in. Then the context switches to using the configuration in the XML file when the logging subsystem is processed. This is done as early as it can be done, but clearly can't happen immediately which is why we have the need for an additional logging configuration file (logging.properties) .

What used to happen is when it switched from the boot configuration to the XML configuration using services, there was a brief time when log statements could be lost in the switch. By using a new configuration manager in JBoss Log Manager the switch between the two is much more seamless. No new log context is created and any additional configuration is just added to the original context. The configuration manager in the JBoss Log Manager writes the logging.properties file with the configuration it has. So if no changes were made in the XML, then the next time the server boots nothing will be changed when the logging subsystem boots.

From my personal perspective I do think it would be great to write properties back to the logging.properties file, but the log manager does not support that. It would be nice it would write out something like ${jboss.server.log.dir:/path/to/previous/log/dir}, but it only writes out the resolved values.

I did create a JIRA[1] to add back a file handler back to the initial logging.properties file. I can't exactly recall the reason I removed it, but if memory serves it had something to do with directory resolution and I think it's been changed anyway.

[1] https://issues.jboss.org/browse/AS7-6045

On 11/26/2012 02: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.

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.


-- 
James R. Perkins
JBoss by Red Hat

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Logging Subsystem Changes

James Perkins
In reply to this post by Brian Stansberry

On 11/27/2012 08:53 AM, Brian Stansberry wrote:

> On 11/27/12 10:44 AM, Andrig Miller wrote:
>>
>> ----- Original Message -----
>>> From: "James Perkins" <[hidden email]>
>>> To: "Stuart Douglas" <[hidden email]>
>>> Cc: "Andrig Miller" <[hidden email]>, "[hidden email] Development"
>>> <[hidden email]>
>>> 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:
>>>
>> This sounds promising.  We certainly won't need the boot log if we can get everything into the server log.
>>
> The trick is the one bit of value the boot.log added was letting through
> all the DEBUG info in category org.jboss.as.config while not having the
> console show it and not having the main server.log log DEBUG.
That should still be case as the console is set to INFO by default and
the server.log has no level set which defaults to ALL.

>
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>

--
James R. Perkins
JBoss by Red Hat

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev