Fantastic - thank you! On Fri, Jan 15, 2021 at 3:11 PM Jean-Louis Monteiro < [email protected]> wrote:
> 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 > >>>> > >>> >
