[jboss-jira] [JBoss JIRA] (AS7-6053) Reconsider post-boot logging of management operation errors

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/AS7-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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