[jboss-jira] [JBoss JIRA] (AS7-5724) Fix logging rollback handlers

Brian Stansberry (JIRA) jira-events at lists.jboss.org
Thu Oct 11 15:25:03 EDT 2012


    [ https://issues.jboss.org/browse/AS7-5724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725715#comment-12725715 ] 

Brian Stansberry edited comment on AS7-5724 at 10/11/12 3:24 PM:
-----------------------------------------------------------------

Semi-OT: Note also the addition of the new OperationContext.completeStep(ResultHandler resultHandler) method, which may prove useful in these handlers.

I was thinking in particular about something like always needing to call logContextIForgetWhat.forget() whether or not the operation succeeded. If the deprecated context.completeStep() was used that could be done in a finally block. The completeStep(ResultHandler resultHandler) variant can provide a similar behavior. The only difference is if the OSH throws an exception before calling completeStep(resultHandler) -- a finally block deals with that. If that's an issue, I just set a boolean to true after calling completeStep(resultHandler) and in the finally block only take action if that boolean isn't set:

{code}
boolean completeStepCalled = false;
doSomethingRequiringCleanup();
try {  
  doSomethingThatMayThrowOFEorRuntimeException();

  context.completeStep(new ResultHandler() 
    { public void handleResult(....) {
        doCleanup();
    }
  });
  completeStepCalled = true;
} finally {
    if (!completeStepCalled) {
       doCleanup();
    }
}
{code}  

                
      was (Author: brian.stansberry):
    Semi-OT: Note also the addition of the new OperationContext.completeStep(ResultHandler resultHandler) method, which may prove useful in these handlers.

I was thinking in particular about something like always needing to call logContextIForgetWhat.forget() whether or not the operation succeeded. If the deprecated context.completeStep() was used that could be done in a finally block. The completeStep(ResultHandler resultHandler) variant can provide a similar behavior. The only difference is if the OSH throws an exception before calling completeStep(resultHandler) -- a finally block deals with that. If that's an issue, I just set a boolean to true after calling completeStep(resultHandler) and in the finally block only take action if that boolean isn't set:


boolean completeStepCalled = false;
doSomethingRequiringCleanup();
try {  
  doSomethingThatMayThrowOFEorRuntimeException();

  context.completeStep(new ResultHandler() 
    { public void handleResult(....) {
        doCleanup();
    }
  });
  completeStepCalled = true;
} finally {
    if (!completeStepCalled) {
       doCleanup();
    }
}
  

                  
> Fix logging rollback handlers
> -----------------------------
>
>                 Key: AS7-5724
>                 URL: https://issues.jboss.org/browse/AS7-5724
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Logging rollback handlers don't seem to be working at all. Really a snapshot should be taken of the LogContext or at least it's configuration and then rolledback in the rollback handler. Re-executing the opposite OSH (e.g. remove rollback invokes add) could be invoked in the incorrect order causing errors rolling back.

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


More information about the jboss-jira mailing list