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 >
