You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2010/06/25 05:25:15 UTC
Re: EJB 3.1 @Schedule support
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
Re: EJB 3.1 @Schedule support
Posted by Ivan <xh...@gmail.com>.
You are so fast :-)
2010/7/15 Gurkan Erdogdu <gu...@yahoo.com>
> >>>>https://issues.apache.org/jira/browse/OPENEJB-1164
> >>>Basically, the callbacks of a singleton are allowed to be transactional
> just
> >>>like business methods.
>
> I have added initial patch for this. Could you review?
>
>
> Thanks;
>
> --Gurkan
>
>
> ________________________________
> From: David Blevins <da...@visi.com>
> To: dev@openejb.apache.org
> Sent: Thu, July 15, 2010 5:02:43 AM
> Subject: Re: EJB 3.1 @Schedule support
>
>
> On Jul 14, 2010, at 6:33 PM, Ivan wrote:
>
> > 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.
>
> That sounds like a good idea. We still have some @Singleton work to be
> done.
> This one in particular:
>
> https://issues.apache.org/jira/browse/OPENEJB-1164
>
> Basically, the callbacks of a singleton are allowed to be transactional
> just
> like business methods.
>
> -David
>
>
> > 2010/7/14 Ivan <xh...@gmail.com>
> >
> >> 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 <da...@visi.com>
> >>
> >>
> >>> 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 <da...@visi.com>
> >>>>
> >>>>> 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
>
>
--
Ivan
Re: EJB 3.1 @Schedule support
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
>>>>https://issues.apache.org/jira/browse/OPENEJB-1164
>>>Basically, the callbacks of a singleton are allowed to be transactional just
>>>like business methods.
I have added initial patch for this. Could you review?
Thanks;
--Gurkan
________________________________
From: David Blevins <da...@visi.com>
To: dev@openejb.apache.org
Sent: Thu, July 15, 2010 5:02:43 AM
Subject: Re: EJB 3.1 @Schedule support
On Jul 14, 2010, at 6:33 PM, Ivan wrote:
> 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.
That sounds like a good idea. We still have some @Singleton work to be done.
This one in particular:
https://issues.apache.org/jira/browse/OPENEJB-1164
Basically, the callbacks of a singleton are allowed to be transactional just
like business methods.
-David
> 2010/7/14 Ivan <xh...@gmail.com>
>
>> 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 <da...@visi.com>
>>
>>
>>> 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 <da...@visi.com>
>>>>
>>>>> 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
Re: EJB 3.1 @Schedule support
Posted by David Blevins <da...@visi.com>.
On Jul 14, 2010, at 6:33 PM, Ivan wrote:
> 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.
That sounds like a good idea. We still have some @Singleton work to be done. This one in particular:
https://issues.apache.org/jira/browse/OPENEJB-1164
Basically, the callbacks of a singleton are allowed to be transactional just like business methods.
-David
> 2010/7/14 Ivan <xh...@gmail.com>
>
>> 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 <da...@visi.com>
>>
>>
>>> 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 <da...@visi.com>
>>>>
>>>>> 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
Re: EJB 3.1 @Schedule support
Posted by Ivan <xh...@gmail.com>.
Hi, David
The first two features have been implemented, see the test case :
testMinusDayOfMonth and testEndTime
2010/7/31 David Blevins <da...@visi.com>
>
> On Jul 14, 2010, at 6:33 PM, Ivan wrote:
>
> > 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.
>
> Hi Ivan,
>
> Finally got a chance to review this patch and get it checked in. I closed
> out most of these tasks:
>
> https://issues.apache.org/jira/browse/OPENEJB-1136
>
> I added these to indicate work still left to be completed:
>
> OPENEJB-1316: Support dayOfWeek and dayOfMonth in the same Schedule
> expression
> OPENEJB-1318: Support negative (-) in dayOfMonth to indicate days from the
> end of the month
> OPENEJB-1317: Persistent Timers
>
> Can you think of anything else we still need to do syntax wise? Those were
> the last two I recall that Quartz does not implement.
>
>
> -David
>
>
>
--
Ivan
Re: EJB 3.1 @Schedule support
Posted by David Blevins <da...@visi.com>.
On Jul 14, 2010, at 6:33 PM, Ivan wrote:
> 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.
Hi Ivan,
Finally got a chance to review this patch and get it checked in. I closed out most of these tasks:
https://issues.apache.org/jira/browse/OPENEJB-1136
I added these to indicate work still left to be completed:
OPENEJB-1316: Support dayOfWeek and dayOfMonth in the same Schedule expression
OPENEJB-1318: Support negative (-) in dayOfMonth to indicate days from the end of the month
OPENEJB-1317: Persistent Timers
Can you think of anything else we still need to do syntax wise? Those were the last two I recall that Quartz does not implement.
-David
Re: EJB 3.1 @Schedule support
Posted by Ivan <xh...@gmail.com>.
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 <xh...@gmail.com>
> 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 <da...@visi.com>
>
>
>> 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 <da...@visi.com>
>> >
>> >> 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
Re: EJB 3.1 @Schedule support
Posted by Ivan <xh...@gmail.com>.
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 <da...@visi.com>
>
> 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 <da...@visi.com>
> >
> >> 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
Re: EJB 3.1 @Schedule support
Posted by David Blevins <da...@visi.com>.
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 <da...@visi.com>
>
>> 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
Re: EJB 3.1 @Schedule support
Posted by Ivan <xh...@gmail.com>.
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 <da...@visi.com>
> 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