Went ahead and merged this PR and marked the jira as being resolved. I'm waiting for the build to finish and I'll fire a new TCK run over the weekend maybe so we can validate if it fixed or not the issue. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
On Thu, Jan 14, 2021 at 10:52 AM Jean-Louis Monteiro < [email protected]> wrote: > 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 >>>> >>>
