[
https://issues.jboss.org/browse/WFLY-11548?page=com.atlassian.jira.plugin...
]
Omar Hefnawi updated WFLY-11548:
--------------------------------
Steps to Reproduce: I honestly think the git branch gives you the best idea on how to
recreate it, it's a small change, but it requires you to somewhat violate the spec by
extending a RemoteException with one of your own. This bug happens in
CMTTxInterceptor.java:239 in conjunction with EJBComponent.java:266 (was: I honestly
think the Pull Request gives you the best idea on how to recreate it, it's a small
change, but it requires you to somewhat violate the spec by extending a RemoteException
with one of your own. This bug happens in CMTTxInterceptor.java:239 in conjunction with
EJBComponent.java:266)
RemoteExceptions and subclasses treated as ApplicationExceptions
----------------------------------------------------------------
Key: WFLY-11548
URL:
https://issues.jboss.org/browse/WFLY-11548
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 13.0.0.Final
Environment: - Windows
- Wildfly 13 final
- Java sdk 1.8
Reporter: Omar Hefnawi
Priority: Major
Remote Exceptions should be treated as if they are System Exceptions
So in very old projects where they used to extend RemoteException for their own
exceptions, code was written under the assumption that when one of these is caught in the
container, the transaction should be rolled back as per the spec (system exceptions cause
a rollback).
Currently if an ejb method throws a remote exception, this will be translated to be
an Application Exception (on line 275 in EJBComponent.java) and transactions that are
currently happening will no longer be rolled back; which was against the old spec, I'm
unsure of what ejb 3.X says about this, but currently I felt it would make sense to mimic
what happened in older application containers.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)