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.
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 ?
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
