Re: [TCK] EJB 3.2 timers
thanks for sharing the awesome news! El lun, 18 ene 2021 a las 7:51, Jean-Louis Monteiro (< jlmonte...@tomitribe.com>) escribió: > 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 < > jonathan.gallim...@gmail.com> wrote: > > > Fantastic - thank you! > > > > On Fri, Jan 15, 2021 at 3:11 PM Jean-Louis Monteiro < > > jlmonte...@tomitribe.com> 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 < > > > jlmonte...@tomitribe.com> 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 < > > > > jlmonte...@tomitribe.com> 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 < > > > >> jlmonte...@tomitribe.com> 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 < > > > >>> richard.zowa...@hs-heilbronn.de> 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.(EJBCronTrigger. > > > > > java:121) > > > > >at > > > > > > > > org.apache.openejb.core.timer.CalendarTimerData.initializeTrigger(C > > > >
Re: [TCK] EJB 3.2 timers
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 < jonathan.gallim...@gmail.com> wrote: > Fantastic - thank you! > > On Fri, Jan 15, 2021 at 3:11 PM Jean-Louis Monteiro < > jlmonte...@tomitribe.com> 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 < > > jlmonte...@tomitribe.com> 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 < > > > jlmonte...@tomitribe.com> 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 < > > >> jlmonte...@tomitribe.com> 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 < > > >>> richard.zowa...@hs-heilbronn.de> 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.(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:
Re: [TCK] EJB 3.2 timers
Fantastic - thank you! On Fri, Jan 15, 2021 at 3:11 PM Jean-Louis Monteiro < jlmonte...@tomitribe.com> 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 < > jlmonte...@tomitribe.com> 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 < > > jlmonte...@tomitribe.com> 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 < > >> jlmonte...@tomitribe.com> 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 < > >>> richard.zowa...@hs-heilbronn.de> 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.(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 except
Re: [TCK] EJB 3.2 timers
Thanks for the update - I scanned the changes yesterday. Couldn't find anything weird. So I am curious of the TCK results. Gruss Richard Am Freitag, den 15.01.2021, 16:11 +0100 schrieb Jean-Louis Monteiro: > 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 < > jlmonte...@tomitribe.com> 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 < > > jlmonte...@tomitribe.com> 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 < > > > jlmonte...@tomitribe.com> 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 < > > > > richard.zowa...@hs-heilbronn.de> 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.s > > > > > > > etEndTime( > > > > > > > CronTriggerImpl.java:417) > > > > > > >at > > > > > > > org.apache.openejb.core.timer.EJBCronTrigger.(EJBCr > > > > > > > onTrigger. > > > > > > > java:121) > > > > > > >at > > > > > > > org.apache.openejb.core.timer.CalendarTimerData.initializ > > > > > > > eTrigger(C > > > > > > > alendarTimerData.java:61) > > > > > > >at > > > > > > > org.apache.openejb.core.timer.TimerData.newTimer(TimerDat > > > > > > > a.java:222 > > > > > > > ) > > > > > > >at > > > > > > > org.apache.openejb.core.timer.EjbTimerServiceImpl.initial > > > > > > > izeNewTime > > > > > > > r(EjbTimerServiceImpl.java:738) > > > > > > >at > > > > > > > org.apache.openejb.core.timer.EjbTimerServiceImpl.createT > > > > > > > i
Re: [TCK] EJB 3.2 timers
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 < jlmonte...@tomitribe.com> 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 < > jlmonte...@tomitribe.com> 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 < >> jlmonte...@tomitribe.com> 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 < >>> richard.zowa...@hs-heilbronn.de> 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.(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 > t
Re: [TCK] EJB 3.2 timers
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 < jlmonte...@tomitribe.com> 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 < > jlmonte...@tomitribe.com> 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 < >> richard.zowa...@hs-heilbronn.de> 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.(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 >>> >>
Re: [TCK] EJB 3.2 timers
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 < jlmonte...@tomitribe.com> 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 < > richard.zowa...@hs-heilbronn.de> 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.(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 >> >
Re: [TCK] EJB 3.2 timers
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 < richard.zowa...@hs-heilbronn.de> 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.(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 >
Re: [TCK] EJB 3.2 timers
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.(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 smime.p7s Description: S/MIME cryptographic signature
[TCK] EJB 3.2 timers
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.(EJBCronTrigger.java:121) >at > org.apache.openejb.core.timer.CalendarTimerData.initializeTrigger(CalendarTimerData.java:61) >at org.apache.openejb.core.timer.TimerData.newTimer(TimerData.java:222) >at > org.apache.openejb.core.timer.EjbTimerServiceImpl.initializeNewTimer(EjbTimerServiceImpl.java:738) >at > org.apache.openejb.core.timer.EjbTimerServiceImpl.createTimer(EjbTimerServiceImpl.java:715) >at > org.apache.openejb.core.timer.TimerServiceImpl.createCalendarTimer(TimerServiceImpl.java:83) >at > org.apache.openejb.core.timer.TimerServiceWrapper.createCalendarTimer(TimerServiceWrapper.java:79) >at > com.sun.ts.tests.ejb30.timer.common.TimerBeanBaseWithoutTimeOutMethod.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