Hi, David:
I am thinking that since the persistent support is not included in the
web profile, maybe I could try to work on those features belong to EJB 3.1
Lite. Not sure how many features have been covered, hope to get some
comments from you.
Thanks !
2010/7/14 Ivan <[email protected]>
> 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
>
--
Ivan
