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