You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomee.apache.org by Jean-Louis Monteiro <jl...@tomitribe.com> on 2020/11/18 21:52:01 UTC

[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.<init>(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

Re: [TCK] EJB 3.2 timers

Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.

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 <
> jlmonteiro@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 <
> > jlmonteiro@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 <
> > > jlmonteiro@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.zowalla@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.<init>(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
> > > > > > > imer(EjbTi
> > > > > > > merServiceImpl.java:715)
> > > > > > >    at
> > > > > > > org.apache.openejb.core.timer.TimerServiceImpl.createCale
> > > > > > > ndarTimer(
> > > > > > > TimerServiceImpl.java:83)
> > > > > > >    at
> > > > > > > org.apache.openejb.core.timer.TimerServiceWrapper.createC
> > > > > > > alendarTim
> > > > > > > er(TimerServiceWrapper.java:79)
> > > > > > >    at
> > > > > > > com.sun.ts.tests.ejb30.timer.common.TimerBeanBaseWithoutT
> > > > > > > imeOutMeth
> > > > > > > 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
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791
mail: richard.zowalla@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/