[
https://issues.jboss.org/browse/WFLY-2967?page=com.atlassian.jira.plugin....
]
Stuart Douglas commented on WFLY-2967:
--------------------------------------
I have removed this behaviour, we already have some rather unfortunate log and re-throw
behaviour in the logging interceptor, which basically means that at the moment an
exception may be logged twice for every EJB on the call stack (e.g. a servlet that called
a chain of 3 EJB's could result in the exception being logged 7 times).
This should never have been there in the first place IMHO.
Rationalize log-and-throw behavior in
CMTTxInterceptor.handleInCallerTx
-----------------------------------------------------------------------
Key: WFLY-2967
URL:
https://issues.jboss.org/browse/WFLY-2967
Project: WildFly
Issue Type: Task
Components: EJB
Affects Versions: 8.0.0.Final
Reporter: Brian Stansberry
Assignee: Stuart Douglas
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 was sent by Atlassian JIRA
(v6.3.11#6341)