-
Notifications
You must be signed in to change notification settings - Fork 119
Description
The two tests with LockSingletonTimerBeanBase have the following code snippet:
try {
t.getNextTimeout();
} catch (NoMoreTimeoutsException nmto) {
// ignore
}
Other tests in the TCK that cover this function catch and ignore both NoMoreTimeoutsException and NoSuchObjectLocalException (see ejb30/timer/common/TimerBeanBaseWithoutTimeOutMethod.passIfNoMoreTimeouts() for example).
Given that these two tests are performing Timer calls from within PostConstruct and PreDestroy methods (and not from within a Timeout method) one could argue that NoSuchObjectLocalException is the only correct expected exception in this case, but since the TCK has treated NoMoreTimeoutsException as valid up to now it's probably best to just leave it there.
EJB 3.2 13.2.5.3 says:
If the timer is a calendar-based timer, the container removes the timer after the timeout callback method has been successfully invoked (e.g., when the transaction that has been started for the invocation of the timeout callback method commits) and there are no future timeouts corresponding to the timer’s schedule expression. If any method is invoked on the timer after it has been removed, the NoSuchObjectLocalException must be thrown. If the bean invokes the getNextTimeout or getTimeRemaining method on the timer associated with a timeout callback while within the timeout callback, and there are no future timeouts for this calendar-based timer, the NoMoreTimeoutsException must be thrown.
All of the above would also apply to the calls to getTimeRemaining().