[jboss-jira] [JBoss JIRA] (WFLY-2967) Rationalize log-and-throw behavior in CMTTxInterceptor.handleInCallerTx

[Scott Marlow (JIRA)]

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

Scott Marlow commented on WFLY-2967:
------------------------------------

If the thrown exception causes a CNFE on the client side (e.g. because of some missing jar), the server side log is the only place that contains the exception call stack as the client side logging fails (with the CNFE).  The workaround for the client would be to add the missing jar onto its classpath, so that the exception can be logged next time.  

I remember that we talked about flattening remote exceptions to avoid CNFEs.  I don't remember how many years ago that was (could of been around AS 4.x timeframe or more recent, I forget ;)  I don't think we ever actually tried flattening remote exceptions.
                
> Rationalize log-and-throw behavior in CMTTxInterceptor.handleInCallerTx
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2967
>                 URL: https://issues.jboss.org/browse/WFLY-2967
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: David Lloyd
>
> CMTTxInterceptor.handleInCallerTx does a log-and-throw:
> {code}
>         setRollbackOnly(tx);
>         EjbLogger.ROOT_LOGGER.error(t);
>         throw (Exception) t;
> {code}
> Generally this is an anti-pattern, although there may be utility in logging some events server-side as an aid in diagnostics or something. IMO if the exception indicates some sort of server fault, as opposed to a client or application state mistake, it needs to be logged server-side. But I'm not sure where the dividing line is.
> It doesn't look like this particular example is nicely playing such a role though.
> 1) It's only called in MANDATORY/REQUIRED/SUPPORTS scenarios where a tx already exists. So, what it logs is logged in some scenarios and not in others.
> 2) It logs stuff that looks pretty clearly like client mistakes, in particular NoSuchEJBException and NoSuchEntityException. I don't believe these add value to the server log, at least not at a level above DEBUG.
>  

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