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 < > [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.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: [email protected] web: https://www.mi.hs-heilbronn.de/
smime.p7s
Description: S/MIME cryptographic signature
