Hi, David:
Finally, I attached the patch for scheduler support to jiar 1168. Please
check the comments in that jira, some functions are still in investigation.
For the ejb cron trigger, currently, I still use our own, after some
updates, it should support all the schedule expression features. About the
persistent support, as you mentioned, it is not of high priority, I will
check whether we could take advantage of Quartz.
Thanks !
2010/7/8 David Blevins <[email protected]>
>
> On Jul 7, 2010, at 6:18 PM, Ivan wrote:
>
> > Hi, David:
> > Thanks for the info. Currently, most codes for schdule itself are
> done.
> > Two issues are left :
> > a. The first one is for EJBCronTrigger, while trying to use the
> existing
> > one, I found that it might not implete the all the required cron
> functions.
> > I also checked the latest Quartz 1.8.3, those two missing functions are
> sill
> > not covered. Seems that the only ways now is to continue to working our
> own
> > EJBCronTrigger.
>
> Maybe we should email Quartz and see if they'll implement the missing
> functionality. Even if they don't, it might be possible to avoid the
> dayOfWeek + dayOfMonth issue if the TCK doesn't test it. It would still be
> broken, but if it can pass the TCK that would buy us a little time to fix it
> more properly after a certified release. Then we could take all the time we
> need to do a more robust impl if we wanted.
>
> > b. Another thing is for the persistent support, one way is to take
> > advantage of quartz, it does have some simliar function, but we might
> loss
> > the control for it. Another ways is to create our own way to do it, use
> text
> > file, db or something else. Any comment for it ?
>
> I'm not too sure on persistence. Currently we don't really do any
> persistence at all. Would probably want to know more about any potential
> Quartz related persistence before commenting more. Not too critical to
> solve in the immediate term as @Schedule isn't needed for the Java EE 6 Web
> Profile, but if we can get non-persistent @Schedule support in that would be
> great. We can do the persistent work after the Web Profile completion if it
> looks like it might be hard.
>
> -David
>
>
> >
> > 2010/6/25 David Blevins <[email protected]>
> >
> >> Hey Ivan,
> >>
> >> As you're probably noticing already, the @Schedule support was attempted
> >> before. I had basically written most of the deployment part of that
> code
> >> and someone else was working on a fancy version of the scheduler itself
> --
> >> that's where the real work is anyway. Here was that thread:
> >>
> >>
> >>
> http://openejb.979440.n4.nabble.com/EJB-3-1-Schedule-support-td988002.html
> >>
> >> This was all before the EJB 3.1 spec closed and things did change
> somewhat
> >> in the final version, so be on the lookout for old code :)
> >>
> >> On Oct 31, 2008, at 12:35 PM, David Blevins wrote:
> >>
> >>> Anyway, I wrapped up ScheduleExpression and TimerConfig into an object,
> >> ScheduleData, and assocted a list of those to a method via a new
> >> MethodSchedule object. Then I adjusted DeploymentInfo to return a list
> of
> >> MethodSchedule objects. So no need to pass in a method as before. I
> had
> >> modeled the code after the interceptor binding code where passing in a
> >> method is more convenient than getting all the bindings for all the
> methods,
> >> but here that obviously doesn't make sense. At least it's more obvious
> once
> >> you've pointed it out to me :)
> >>>
> >>> We should be good to go on the metadata aggregation side.
> >>
> >> Just updated this code to be more in line with the new MethodContext
> >> concept. Basically, the ScheduleData list has been moved right into
> >> MethodContext, which should be a little cleaner. The now unneeded
> >> MethodSchedule object has been removed
> >>
> >> Of course, keep in mind since this is half finished, feel free to change
> >> absolutely any part of it in order to achieve the most elegant result.
> At
> >> this point it's all just a best guess -- you never really know how it's
> >> going to look till it's done :)
> >>
> >>
> >> -David
> >>
> >
> >
> >
> > --
> > Ivan
>
>
--
Ivan
