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
