https://tck.work/tomee/build?id=1610964398253
100% green on EJB32 !!! -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Fri, Jan 15, 2021 at 4:18 PM Jonathan Gallimore < [email protected]> wrote: > 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 > > >>>> > > >>> > > >
