>>>>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 <[email protected]> To: [email protected] 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 <[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
