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 2008/10/16 11:49:02 UTC
EJB 3.1 @Schedule support
Alex Grönholm and I were chatting about what it will take to support
the @Schedule functionality in EJB 3.1. We (the expert group)
introduced some pretty good syntax to deal with a lot of advanced
expressions that go beyond cron. I pulled down the Quartz source and
poked around to see what we'd have to do.
Quartz has pretty much everything we'll need. One thing that Alex
Grönholm pointed out on IRC was that the Quartz cron support does not
allow specification of both dayOfWeek and dayOfMonth. So far EJB 3.1
allows this so it is possible to write a schedule that is executed
every Friday the 13th, for example. That seems to be the only
limitation so far.
Some small differences in syntax. For "first Monday of the month"
Quartz uses "2#1" in EJB 3.1 we chose a more straight forward syntax
of "1st Mon" as we can get away with spaces as we have separate
attributes in the annotation for hour, dayOfWeek, year and so on
rather than one expression string split on a spaces. We also went
with spelling out "Last" instead of just using "L" and the Quartz "6L"
for "last friday of the month" becomes "Last Fri" in EJB 3.1. Other
than that, things are pretty much the same.
One thing EJB 3.1 has that I couldn't find digging in the Quartz
source is "3 days from the end of the month" which can be expressed as
"-3" in the dayOfMonth. Can't yet find a Quartz equivalent.
-David
Re: EJB 3.1 @Schedule support
Posted by David Blevins <da...@visi.com>.
FYI, we need Quartz 1.6.1, but it hasn't been published to the maven
repo. Looks like the most recent Quartz binary is a year or so old.
Feel encouraged to throw a "me too" on this thread asking for it to be
published:
http://forums.opensymphony.com/thread.jspa?messageID=588417򏪁
-David
On Oct 16, 2008, at 2:49 AM, David Blevins wrote:
> Alex Grönholm and I were chatting about what it will take to support
> the @Schedule functionality in EJB 3.1. We (the expert group)
> introduced some pretty good syntax to deal with a lot of advanced
> expressions that go beyond cron. I pulled down the Quartz source
> and poked around to see what we'd have to do.
>
> Quartz has pretty much everything we'll need. One thing that Alex
> Grönholm pointed out on IRC was that the Quartz cron support does
> not allow specification of both dayOfWeek and dayOfMonth. So far
> EJB 3.1 allows this so it is possible to write a schedule that is
> executed every Friday the 13th, for example. That seems to be the
> only limitation so far.
>
> Some small differences in syntax. For "first Monday of the month"
> Quartz uses "2#1" in EJB 3.1 we chose a more straight forward syntax
> of "1st Mon" as we can get away with spaces as we have separate
> attributes in the annotation for hour, dayOfWeek, year and so on
> rather than one expression string split on a spaces. We also went
> with spelling out "Last" instead of just using "L" and the Quartz
> "6L" for "last friday of the month" becomes "Last Fri" in EJB 3.1.
> Other than that, things are pretty much the same.
>
> One thing EJB 3.1 has that I couldn't find digging in the Quartz
> source is "3 days from the end of the month" which can be expressed
> as "-3" in the dayOfMonth. Can't yet find a Quartz equivalent.
>
> -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
Re: EJB 3.1 @Schedule support
Posted by 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
Re: EJB 3.1 @Schedule support
Posted by David Blevins <da...@visi.com>.
On Oct 30, 2008, at 7:43 PM, Alex Grönholm wrote:
> I think we could do with a less complicated solution. As it stands,
> I have to reflectively scan the bean class for methods and then call
> DeploymentInfo.getMethodSchedule() on each to see if the method has
> any schedules on it. CoreDeploymentInfo has a map of method ->
> ScheduleExpression, but there is no way to retrieve that. I will
> also need the persistent and info properties, so why don't you just
> give me a map of method -> ScheduleInfo[] and let me worry about
> building ScheduleExpressions and TimerConfigs? This is somewhat
> blocking my development so it'd be appreciated if you could do that
> in the near future.
You definitely shouldn't need to do any annotation scanning. We don't
have any code that does annotation scanning in the runtime stack, so
if there is some we'll need to find another way of doing it.
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.
-David
Re: EJB 3.1 @Schedule support
Posted by Alex Grönholm <al...@nextday.fi>.
David Blevins kirjoitti:
>
> On Oct 24, 2008, at 3:52 AM, Alex Grönholm wrote:
>
>> David Blevins kirjoitti:
>>> Additionally, I followed standard rules for annotation inheritance
>>> in that overriding a method in a subclass causes the annotations
>>> associated with that method to be "whipped away" unless redeclared
>>> in the overridden method. This matches the rules for all the
>>> callback methods (@PostConstruct, @PreDestroy, @AroundInvoke,
>>> @PrePassivate, @PostActivate).
>>>
>> Had those annotations been meant to be inherited, they would have
>> been marked with @java.lang.annotation.Inherited.
>
> I don't think that works for methods. But, right, the annotation data
> is not "inherited" by the overriding method.
>
>>> One little caveat of doing it this way is that ScheduleExpression
>>> does not encapsulate all the data that is present in @Schedule,
>>> namely it isn't possible to specify 'persistence' or 'info'. For the
>>> first iteration we can go without persistence. But perhaps there
>>> should in fact be a 'public boolean persistent' field in
>>> ScheduleExpression.
>>>
>> that would duplicate functionality in TimerConfig, which allows one
>> to specify both persistence status and info.
>
> Thanks, I missed that class. In which case we'll want to wrap both
> the ScheduleExpression and TimerConfig in an object and return both
> from the DeploymentInfo.getMethodSchedule(..) method.
>
> I'll hack something up on that.
>
I think we could do with a less complicated solution. As it stands, I
have to reflectively scan the bean class for methods and then call
DeploymentInfo.getMethodSchedule() on each to see if the method has any
schedules on it. CoreDeploymentInfo has a map of method ->
ScheduleExpression, but there is no way to retrieve that. I will also
need the persistent and info properties, so why don't you just give me a
map of method -> ScheduleInfo[] and let me worry about building
ScheduleExpressions and TimerConfigs? This is somewhat blocking my
development so it'd be appreciated if you could do that in the near future.
>
> -David
>
Re: EJB 3.1 @Schedule support
Posted by David Blevins <da...@visi.com>.
On Oct 24, 2008, at 3:52 AM, Alex Grönholm wrote:
> David Blevins kirjoitti:
>> Additionally, I followed standard rules for annotation inheritance
>> in that overriding a method in a subclass causes the annotations
>> associated with that method to be "whipped away" unless redeclared
>> in the overridden method. This matches the rules for all the
>> callback methods (@PostConstruct, @PreDestroy, @AroundInvoke,
>> @PrePassivate, @PostActivate).
>>
> Had those annotations been meant to be inherited, they would have
> been marked with @java.lang.annotation.Inherited.
I don't think that works for methods. But, right, the annotation data
is not "inherited" by the overriding method.
>> One little caveat of doing it this way is that ScheduleExpression
>> does not encapsulate all the data that is present in @Schedule,
>> namely it isn't possible to specify 'persistence' or 'info'. For
>> the first iteration we can go without persistence. But perhaps
>> there should in fact be a 'public boolean persistent' field in
>> ScheduleExpression.
>>
> that would duplicate functionality in TimerConfig, which allows one
> to specify both persistence status and info.
Thanks, I missed that class. In which case we'll want to wrap both
the ScheduleExpression and TimerConfig in an object and return both
from the DeploymentInfo.getMethodSchedule(..) method.
I'll hack something up on that.
-David
Re: EJB 3.1 @Schedule support
Posted by Alex Grönholm <al...@nextday.fi>.
David Blevins kirjoitti:
> Great start on the EJBCronTrigger, Alex. I went ahead and applied the
> patch in OPENEJB-928 (thank you!).
>
> I added some code for the annotation scanning and xml overriding
> behavior. Slightly modified from what I posted before.
>
> Now we're looking at something that's a bit closer to the interceptor
> xml syntax, rather than the transaction attribute syntax:
>
> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee">
> <enterprise-beans>
> ...
> </enterprise-beans>
>
> <assembly-descriptor>
> <method-schedule>
> <ejb-name>MyBean</ejb-name>
> <method>
> <method-name>runAction</method-name>
> <method-params/>
> </method>
> <schedule>
> <dayOfMonth>6</dayOfMonth>
> <month>2</month>
> <year>2009</year>
> </schedule>
> <schedule>
> <dayOfMonth>30</dayOfMonth>
> <month>3</month>
> <year>2009</year>
> </schedule>
> </method-schedule>
> </assembly-descriptor>
> </ejb-jar>
>
> Though not visible here there are big difference in that there is only
> one allowed method, that method must have parameters and the binding
> itself is stuck to an ejb-name. The transaction and security xml
> bindings actually allow several ejbs and methods to be mentioned which
> just complicates things in this scenario. I also made it so that if
> you supply a <method-schedule> for a method of an EJB in xml, then it
> is considered an override of the annotation schedule information in
> the class for that method. So it is possible to shut off scheduling
> for a method with a declaration like so:
>
> <method-schedule>
> <ejb-name>MyBean</ejb-name>
> <method>
> <method-name>runAction</method-name>
> <method-params/>
> </method>
> </method-schedule>
>
> Additionally, I followed standard rules for annotation inheritance in
> that overriding a method in a subclass causes the annotations
> associated with that method to be "whipped away" unless redeclared in
> the overridden method. This matches the rules for all the callback
> methods (@PostConstruct, @PreDestroy, @AroundInvoke, @PrePassivate,
> @PostActivate). For example:
>
> public class Parent {
> @Schedules({
> @Schedule(dayOfMonth = "6", month = "2", year = "2009"),
> @Schedule(dayOfMonth = "30", month = "3", year = "2009")
> })
> public void runAction() {
> }
> }
>
Had those annotations been meant to be inherited, they would have been
marked with @java.lang.annotation.Inherited.
>
> public class MyBean extends Parent {
>
> /**
> * Overriding this method without
> * re-annotating it causes it to no longer
> * be treated as an @Schedule method
> */
> public void runAction() {
> }
> }
>
>
> On the deployment side of things, all the sources of data are read in,
> the rules are enforced, and the result is that DeploymentInfo now has
> a method like so:
>
> public List<ScheduleExpression> getMethodSchedules(Method method);
>
> There'll be one javax.ejb.ScheduleExpression list associated with each
> method, or null if there are no schedules for that method.
>
> One little caveat of doing it this way is that ScheduleExpression does
> not encapsulate all the data that is present in @Schedule, namely it
> isn't possible to specify 'persistence' or 'info'. For the first
> iteration we can go without persistence. But perhaps there should in
> fact be a 'public boolean persistent' field in ScheduleExpression.
>
No, that would duplicate functionality in TimerConfig, which allows one
to specify both persistence status and info.
Calendar based timers will be created through
TimerService.createTimer(ScheduleExpression, TimerConfig) (or the
corresponding method in EJBTimerService in the absence of the updated
TimerService interface).
>
> -David
>
Re: EJB 3.1 @Schedule support
Posted by David Blevins <da...@visi.com>.
Great start on the EJBCronTrigger, Alex. I went ahead and applied the
patch in OPENEJB-928 (thank you!).
I added some code for the annotation scanning and xml overriding
behavior. Slightly modified from what I posted before.
Now we're looking at something that's a bit closer to the interceptor
xml syntax, rather than the transaction attribute syntax:
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee">
<enterprise-beans>
...
</enterprise-beans>
<assembly-descriptor>
<method-schedule>
<ejb-name>MyBean</ejb-name>
<method>
<method-name>runAction</method-name>
<method-params/>
</method>
<schedule>
<dayOfMonth>6</dayOfMonth>
<month>2</month>
<year>2009</year>
</schedule>
<schedule>
<dayOfMonth>30</dayOfMonth>
<month>3</month>
<year>2009</year>
</schedule>
</method-schedule>
</assembly-descriptor>
</ejb-jar>
Though not visible here there are big difference in that there is only
one allowed method, that method must have parameters and the binding
itself is stuck to an ejb-name. The transaction and security xml
bindings actually allow several ejbs and methods to be mentioned which
just complicates things in this scenario. I also made it so that if
you supply a <method-schedule> for a method of an EJB in xml, then it
is considered an override of the annotation schedule information in
the class for that method. So it is possible to shut off scheduling
for a method with a declaration like so:
<method-schedule>
<ejb-name>MyBean</ejb-name>
<method>
<method-name>runAction</method-name>
<method-params/>
</method>
</method-schedule>
Additionally, I followed standard rules for annotation inheritance in
that overriding a method in a subclass causes the annotations
associated with that method to be "whipped away" unless redeclared in
the overridden method. This matches the rules for all the callback
methods (@PostConstruct, @PreDestroy, @AroundInvoke, @PrePassivate,
@PostActivate). For example:
public class Parent {
@Schedules({
@Schedule(dayOfMonth = "6", month = "2", year = "2009"),
@Schedule(dayOfMonth = "30", month = "3", year = "2009")
})
public void runAction() {
}
}
public class MyBean extends Parent {
/**
* Overriding this method without
* re-annotating it causes it to no longer
* be treated as an @Schedule method
*/
public void runAction() {
}
}
On the deployment side of things, all the sources of data are read in,
the rules are enforced, and the result is that DeploymentInfo now has
a method like so:
public List<ScheduleExpression> getMethodSchedules(Method method);
There'll be one javax.ejb.ScheduleExpression list associated with each
method, or null if there are no schedules for that method.
One little caveat of doing it this way is that ScheduleExpression does
not encapsulate all the data that is present in @Schedule, namely it
isn't possible to specify 'persistence' or 'info'. For the first
iteration we can go without persistence. But perhaps there should in
fact be a 'public boolean persistent' field in ScheduleExpression.
-David
Re: EJB 3.1 @Schedule support
Posted by Alex Grönholm <al...@nextday.fi>.
David Blevins kirjoitti:
>
> On Oct 16, 2008, at 2:55 AM, Alex Grönholm wrote:
>
>> I'm already in the process of writing a new quartz Trigger to solve
>> these problems. I'll keep you updated on my progress.
>
> Started working on the related @Schedule annotation processing. So
> far have some basic xml setup to hold the annotation data. Modeled it
> after the xml for the security, transaction, and concurrency xml.
>
Good to hear. I'm still busy with EJBCronTrigger, but hopefully I'll
have something to show by the end of the day.
> Here's what I came up with...
>
> A bean declared like so:
>
> public static class MyBean {
> @Schedules({
> @Schedule(dayOfMonth = "6", month = "2", year = "2009"),
> @Schedule(dayOfMonth = "30", month = "3", year = "2009")
> })
> public void runAction() {
> }
> }
>
> Would result in the following xml:
>
> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee">
> <enterprise-beans>
> ...
> </enterprise-beans>
>
> <assembly-descriptor>
> <method-schedule>
> <schedule>
> <dayOfMonth>6</dayOfMonth>
> <month>2</month>
> <year>2009</year>
> </schedule>
> <schedule>
> <dayOfMonth>30</dayOfMonth>
> <month>3</month>
> <year>2009</year>
> </schedule>
> <method>
> <ejb-name>MyBean</ejb-name>
> <method-name>runAction</method-name>
> <method-params/>
> </method>
> </method-schedule>
> </assembly-descriptor>
> </ejb-jar>
>
> Still have to hookup the code that processes the @Schedule annotation
> into the jaxb tree (i.e. the xml) in the AnnotationDeployer, but will
> likely get that in tomorrow. The goal is to get it into the
> EjbJarInfo fully validated so that it can be hooked up in the
> Assembler whenever we get something with Quartz working.
>
> -David
>
>
>
Re: EJB 3.1 @Schedule support
Posted by David Blevins <da...@visi.com>.
On Oct 16, 2008, at 2:55 AM, Alex Grönholm wrote:
> I'm already in the process of writing a new quartz Trigger to solve
> these problems. I'll keep you updated on my progress.
Started working on the related @Schedule annotation processing. So
far have some basic xml setup to hold the annotation data. Modeled it
after the xml for the security, transaction, and concurrency xml.
Here's what I came up with...
A bean declared like so:
public static class MyBean {
@Schedules({
@Schedule(dayOfMonth = "6", month = "2", year = "2009"),
@Schedule(dayOfMonth = "30", month = "3", year = "2009")
})
public void runAction() {
}
}
Would result in the following xml:
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee">
<enterprise-beans>
...
</enterprise-beans>
<assembly-descriptor>
<method-schedule>
<schedule>
<dayOfMonth>6</dayOfMonth>
<month>2</month>
<year>2009</year>
</schedule>
<schedule>
<dayOfMonth>30</dayOfMonth>
<month>3</month>
<year>2009</year>
</schedule>
<method>
<ejb-name>MyBean</ejb-name>
<method-name>runAction</method-name>
<method-params/>
</method>
</method-schedule>
</assembly-descriptor>
</ejb-jar>
Still have to hookup the code that processes the @Schedule annotation
into the jaxb tree (i.e. the xml) in the AnnotationDeployer, but will
likely get that in tomorrow. The goal is to get it into the
EjbJarInfo fully validated so that it can be hooked up in the
Assembler whenever we get something with Quartz working.
-David
Re: EJB 3.1 @Schedule support
Posted by Alex Grönholm <al...@nextday.fi>.
David Blevins kirjoitti:
> Alex Grönholm and I were chatting about what it will take to support
> the @Schedule functionality in EJB 3.1. We (the expert group)
> introduced some pretty good syntax to deal with a lot of advanced
> expressions that go beyond cron. I pulled down the Quartz source and
> poked around to see what we'd have to do.
>
> Quartz has pretty much everything we'll need. One thing that Alex
> Grönholm pointed out on IRC was that the Quartz cron support does not
> allow specification of both dayOfWeek and dayOfMonth. So far EJB 3.1
> allows this so it is possible to write a schedule that is executed
> every Friday the 13th, for example. That seems to be the only
> limitation so far.
>
> Some small differences in syntax. For "first Monday of the month"
> Quartz uses "2#1" in EJB 3.1 we chose a more straight forward syntax
> of "1st Mon" as we can get away with spaces as we have separate
> attributes in the annotation for hour, dayOfWeek, year and so on
> rather than one expression string split on a spaces. We also went
> with spelling out "Last" instead of just using "L" and the Quartz "6L"
> for "last friday of the month" becomes "Last Fri" in EJB 3.1. Other
> than that, things are pretty much the same.
>
> One thing EJB 3.1 has that I couldn't find digging in the Quartz
> source is "3 days from the end of the month" which can be expressed as
> "-3" in the dayOfMonth. Can't yet find a Quartz equivalent.
>
> -David
>
I'm already in the process of writing a new quartz Trigger to solve
these problems. I'll keep you updated on my progress.