Here is the PR https://github.com/apache/tomee/pull/749
I'm building locally and I'll run the EJB32 related tests locally first -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Thu, Jan 14, 2021 at 10:45 AM Jean-Louis Monteiro < [email protected]> wrote: > Hi community, > > Finally got some time to think about this and fix it (I think ;-) ) > > There is one scenario where it is relevant. > Let's imagine you restart an application, the timer may have expired > because the end is already in the past, but we don't want to have to change > the binary in order to set a valid end date to restart a server. > > In that case, we are expecting the server to successfully start, but the > timer to never trigger. > > I'll create a PR so you can double check before I merge it. > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com > > > On Thu, Nov 19, 2020 at 9:08 AM Jean-Louis Monteiro < > [email protected]> wrote: > >> Thanks Richard for the quick feedback. >> >> I am totally with you. Can't think of a valid reason to do that or even >> think it should be a tested requirement in TCK. >> If using endTime before startTime is the only way to specify a timer >> never expires, something is wrong to me. >> >> I'll go ahead and see if I can adjust and at the same time raise an issue >> on the TCK/EE side. >> >> -- >> Jean-Louis Monteiro >> http://twitter.com/jlouismonteiro >> http://www.tomitribe.com >> >> >> On Thu, Nov 19, 2020 at 9:03 AM Zowalla, Richard < >> [email protected]> wrote: >> >>> Hi, >>> >>> I think it is a bit odd in this tck test case, that the creation of a >>> timer with an end time before the start time should even be possible, >>> but nevermind :) >>> >>> I do not quite understand the reason why this behaviour was chosen in >>> the first place. I might miss something as I am not long enough in the >>> EE world. >>> >>> The exception itself sounds valid to me. >>> >>> Maybe: >>> >>> For now: Pre-check and adjustment? Seems to be specific to the quartz >>> impl. >>> >>> Parallel: Asking on the TCK/spec lists? >>> >>> Best >>> Richard Z >>> >>> Am Mittwoch, den 18.11.2020, 22:52 +0100 schrieb Jean-Louis Monteiro: >>> > Hi community, >>> > >>> > I found another thing I wanted to discuss and get feedback on. >>> > On the EJB 3.2 section of the TCK we are down to 5 failures all >>> > related to >>> > schedule/timers. >>> > >>> > To run them, use the following command >>> > >>> > ./runtests --web tomee-plume >>> > com.sun.ts.tests.ejb32.lite.timer.schedule.expire.Client >>> > >>> > This is the part failing >>> > >>> > >>> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/ejb32/lite/timer/schedule/expire/Client.java#L231 >>> > >>> > java.lang.IllegalArgumentException: End time cannot be before start >>> > time >>> > > at >>> > > org.apache.openejb.quartz.impl.triggers.CronTriggerImpl.setEndTime( >>> > > CronTriggerImpl.java:417) >>> > > at >>> > > org.apache.openejb.core.timer.EJBCronTrigger.<init>(EJBCronTrigger. >>> > > java:121) >>> > > at >>> > > org.apache.openejb.core.timer.CalendarTimerData.initializeTrigger(C >>> > > alendarTimerData.java:61) >>> > > at >>> > > org.apache.openejb.core.timer.TimerData.newTimer(TimerData.java:222 >>> > > ) >>> > > at >>> > > org.apache.openejb.core.timer.EjbTimerServiceImpl.initializeNewTime >>> > > r(EjbTimerServiceImpl.java:738) >>> > > at >>> > > org.apache.openejb.core.timer.EjbTimerServiceImpl.createTimer(EjbTi >>> > > merServiceImpl.java:715) >>> > > at >>> > > org.apache.openejb.core.timer.TimerServiceImpl.createCalendarTimer( >>> > > TimerServiceImpl.java:83) >>> > > at >>> > > org.apache.openejb.core.timer.TimerServiceWrapper.createCalendarTim >>> > > er(TimerServiceWrapper.java:79) >>> > > at >>> > > com.sun.ts.tests.ejb30.timer.common.TimerBeanBaseWithoutTimeOutMeth >>> > > od.createTimer(TimerBeanBaseWithoutTimeOutMethod.java:140) >>> > > >>> > > >>> > When we want to set the endTime to Quartz, we get the exception above >>> > which >>> > does not sound stupid. >>> > >>> > The test says >>> > >>> > * @testName: endNeverExpires >>> > * >>> > * @test_Strategy: create a timer with year="currentYear - >>> > currentYear+1", >>> > and >>> > * end="currentYear-1". The end value is prior to the year values, and >>> > this >>> > * timer will never expire. Creating this timer will succeed, but any >>> > timer >>> > * method access in a subsequent business method will result in >>> > * NoSuchObjectLocalException. >>> > */ >>> > >>> > So I'm wondering what would be the best way to be compatible in >>> > TomEE. >>> > Any ideas? >>> > >>> > Of course I could do a pre-check and adjust it to null or whatever >>> > relevant >>> > value. >>> > Or should I ask for the TCK/spec mailings lists? >>> > >>> > >>> > >>> > -- >>> > Jean-Louis Monteiro >>> > http://twitter.com/jlouismonteiro >>> > http://www.tomitribe.com >>> >>
