[jboss-jira] [JBoss JIRA] (AS7-6053) Reconsider post-boot logging of management operation errors
[
https://issues.jboss.org/browse/AS7-6053?page=com.atlassian.jira.plugin.s...
]
Brian Stansberry updated AS7-6053:
----------------------------------
Description:
Currently after boot if there is a failure during a management request we log it at DEBUG
or not at all (see AS7-6046 for the not-at-all issue.) The theory is the error is a client
request and the proper error reporting is to propagate the error to the client, which we
do via the operation response.
We need to consider logging some errors in the server log as well. Some errors can impact
the state of the runtime services, and those kinds of errors should not be invisible in
the log.
A simple approach to this would be to log an ERROR message if the problem happened after
Stage.MODEL. Any problems in Stage.MODEL never escape the data structures (i.e. the copy
of the model) associated with the operation's OperationContext, and thus have no
impact to anyone other than the caller.
A further refinement to this would be to only report Stage.RUNTIME errors if the operation
has taken an action implying mutation of the service container
(context.getServiceRegistry(true) or context.removeService(...)).
was:
Currently after boot if there is a failure during a management request we log it at DEBUG
or not at all (see AS7-6046 for the not-at-all issue.) The theory is the error is a client
request and the proper error reporting is to propagate the error to the client, which we
do via the operation response.
We need to consider logging some errors in the server log as well. Some errors can impact
that state of the runtime services, and those kinds of errors should not be invisible in
the log.
A simple approach to this would be to log an ERROR message if the problem happened after
Stage.MODEL. Any problems in Stage.MODEL never escape the data structures (i.e. the copy
of the model) associated with the operation's OperationContext, and thus have no
impact to anyone other than the caller.
A further refinement to this would be to only report Stage.RUNTIME errors if the operation
has taken an action implying mutation of the service container
(context.getServiceRegistry(true) or context.removeService(...)).
Reconsider post-boot logging of management operation errors
-----------------------------------------------------------
Key: AS7-6053
URL: https://issues.jboss.org/browse/AS7-6053
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.3.0.Alpha1
Currently after boot if there is a failure during a management request we log it at DEBUG
or not at all (see AS7-6046 for the not-at-all issue.) The theory is the error is a client
request and the proper error reporting is to propagate the error to the client, which we
do via the operation response.
We need to consider logging some errors in the server log as well. Some errors can impact
the state of the runtime services, and those kinds of errors should not be invisible in
the log.
A simple approach to this would be to log an ERROR message if the problem happened after
Stage.MODEL. Any problems in Stage.MODEL never escape the data structures (i.e. the copy
of the model) associated with the operation's OperationContext, and thus have no
impact to anyone other than the caller.
A further refinement to this would be to only report Stage.RUNTIME errors if the
operation has taken an action implying mutation of the service container
(context.getServiceRegistry(true) or context.removeService(...)).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira