Menu
▾
▴
springframework-developer
|
From: Ivan R. <iv...@we...> - 2003-09-12 09:43:20
|
[Note: I sent this email yesterday but I did not see it arrive to the mailing list. So here is it again.] As part of my project I am building a (simple but capable) cron-like scheduler. Do you think there is a place for it in the Spring framework? It will support both persistent and non-persistent scheduling. I think the scheduler itself should be a JavaBean, capable of executing a given method (with or without parameters) on an object, according to the supplied schedule. Another possibility is to have the scheduler integrated into the context but I'm not sure how smart that would be. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Rod J. <rod...@in...> - 2003-09-12 10:51:10
|
Yes I think this could be useful. I could envisage uses for it. I don't quite understand the "integration with the context" you propose. Couldn't the scheduler be a BeanFactoryAware bean in a context, and its setBeanFactory() method give it access to whatever other beans it needs and also kick off its timer/whatever? Of course it could be configured by its JavaBean properties. Regards, Rod ----- Original Message ----- From: "Ivan Ristic" <iv...@we...> To: <spr...@li...> Sent: Friday, September 12, 2003 10:42 AM Subject: [Springframework-developer] Spring scheduler? > > [Note: I sent this email yesterday but I did not see it arrive to > the mailing list. So here is it again.] > > > As part of my project I am building a (simple but capable) cron-like > scheduler. Do you think there is a place for it in the Spring > framework? It will support both persistent and non-persistent scheduling. > > I think the scheduler itself should be a JavaBean, capable of > executing a given method (with or without parameters) on > an object, according to the supplied schedule. > > Another possibility is to have the scheduler integrated into the > context but I'm not sure how smart that would be. > > -- > ModSecurity (http://www.modsecurity.org) > [ Open source IDS for Web applications ] > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Ivan R. <iv...@we...> - 2003-09-12 11:49:01
|
Rod Johnson wrote:
> Yes I think this could be useful. I could envisage uses for it.
I will study Spring coding and design standards and
come back with more details.
> I don't quite understand the "integration with the context" you propose.
> Couldn't the scheduler be a BeanFactoryAware bean in a context, and its
> setBeanFactory() method give it access to whatever other beans it needs and
> also kick off its timer/whatever?
>
> Of course it could be configured by its JavaBean properties.
Yes. But there is also a case where you want to schedule events
from your code. There are three ways to achieve this:
1) Explicit configuration, create a scheduler and then give
its reference to every bean that needs it.
2) Have the scheduler as a shared object; other beans have to
be ApplicationContext aware, and use a call to sharedObject()
to retrieve the scheduler reference.
3) Add getScheduler() method to ApplicationContext. I actually
don't like this approach. I only mentioned it because it is
a possibility.
From my point of view, 1 and 2 are acceptable options. The third
option would lead to a fat app. context, and I don't see real
benefit there.
Maybe Spring should define certain names (with or without
a namespace) to be reserved for certain services, e.g.
"service.scheduler". People will certainly do this
themselves, perhaps if we do it on a framework level we
can have greater "portability".
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
|
|
From: Mark P. <Mar...@Co...> - 2003-09-12 13:19:20
|
Hi, You might want to check out Doug Lea's Scheduler in his util.concurrent package for a base implementation, maybe wrapped to be more JavaBean friendly. The J2EE timer service in JBoss might be a good place to look as well.... Services are typically singletons, so going to an ApplicationContext/BeanFactory to get a reference to it should be sufficient I would think. BTW, I am following up on Jurgen's advice regarding service lifecycles, modifying my implementation. The scheduler could be an out of the box service, since it should probably only start after all beans have been wired. - Mark > Rod Johnson wrote: >> Yes I think this could be useful. I could envisage uses for it. > > I will study Spring coding and design standards and > come back with more details. > > >> I don't quite understand the "integration with the context" you propose. >> Couldn't the scheduler be a BeanFactoryAware bean in a context, and its >> setBeanFactory() method give it access to whatever other beans it needs >> and >> also kick off its timer/whatever? >> >> Of course it could be configured by its JavaBean properties. > > Yes. But there is also a case where you want to schedule events > from your code. There are three ways to achieve this: > > 1) Explicit configuration, create a scheduler and then give > its reference to every bean that needs it. > > 2) Have the scheduler as a shared object; other beans have to > be ApplicationContext aware, and use a call to sharedObject() > to retrieve the scheduler reference. > > 3) Add getScheduler() method to ApplicationContext. I actually > don't like this approach. I only mentioned it because it is > a possibility. > > From my point of view, 1 and 2 are acceptable options. The third > option would lead to a fat app. context, and I don't see real > benefit there. > > Maybe Spring should define certain names (with or without > a namespace) to be reserved for certain services, e.g. > "service.scheduler". People will certainly do this > themselves, perhaps if we do it on a framework level we > can have greater "portability". > > -- > ModSecurity (http://www.modsecurity.org) > [ Open source IDS for Web applications ] > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Trevor C. <pr...@se...> - 2003-09-12 13:41:32
|
We're currently using Quartz which is another very good/stable open-source and free scheduler (see http://www.part.net/quartz.html). Trevor D. Cook -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Ivan Ristic Sent: September 12, 2003 7:48 AM To: Rod Johnson Cc: spr...@li... Subject: Re: [Springframework-developer] Spring scheduler? Rod Johnson wrote: > Yes I think this could be useful. I could envisage uses for it. I will study Spring coding and design standards and come back with more details. > I don't quite understand the "integration with the context" you propose. > Couldn't the scheduler be a BeanFactoryAware bean in a context, and its > setBeanFactory() method give it access to whatever other beans it needs and > also kick off its timer/whatever? > > Of course it could be configured by its JavaBean properties. Yes. But there is also a case where you want to schedule events from your code. There are three ways to achieve this: 1) Explicit configuration, create a scheduler and then give its reference to every bean that needs it. 2) Have the scheduler as a shared object; other beans have to be ApplicationContext aware, and use a call to sharedObject() to retrieve the scheduler reference. 3) Add getScheduler() method to ApplicationContext. I actually don't like this approach. I only mentioned it because it is a possibility. From my point of view, 1 and 2 are acceptable options. The third option would lead to a fat app. context, and I don't see real benefit there. Maybe Spring should define certain names (with or without a namespace) to be reserved for certain services, e.g. "service.scheduler". People will certainly do this themselves, perhaps if we do it on a framework level we can have greater "portability". -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003 |
|
From: Colin S. <col...@ex...> - 2003-09-12 14:01:29
|
Why not just take advantage of Quartz? It's free, and has an Apache/BSD style license. http://www.part.net/quartz.html http://www.part.net/quartz_features.html We've been using it for a while with good results. Personally, I don't think it's a great idea to add functionality to Spring which duplicates existing projects that are out there and that have open licenses, _unless_ the Spring implementation has some clear advantages. In this respect, maybe what makes sense is some classes to integrate Quartz into Spring... Regards, Colin Ivan Ristic wrote: > > [Note: I sent this email yesterday but I did not see it arrive to > the mailing list. So here is it again.] > > > As part of my project I am building a (simple but capable) cron-like > scheduler. Do you think there is a place for it in the Spring > framework? It will support both persistent and non-persistent scheduling. > > I think the scheduler itself should be a JavaBean, capable of > executing a given method (with or without parameters) on > an object, according to the supplied schedule. > > Another possibility is to have the scheduler integrated into the > context but I'm not sure how smart that would be. > |
|
From: Ivan R. <iv...@we...> - 2003-09-12 14:33:55
|
Colin Sampaleanu wrote: > Why not just take advantage of Quartz? It's free, and has an Apache/BSD > style license. > http://www.part.net/quartz.html > http://www.part.net/quartz_features.html I reviewed Quartz for my project before I decided to wrap my own, and decided against it because it was simply too complex and too intrusive for my taste (and it didn't have/does not have file system persistence). I don't think there is anything wrong with it (besides, I did not program in it I just read the documentation). My friend used to say "Never use a cannon to accomplish what you could with a stick". > We've been using it for a while with good results. Personally, I don't > think it's a great idea to add functionality to Spring which duplicates > existing projects that are out there and that have open licenses, > _unless_ the Spring implementation has some clear advantages. Agreed. > In this > respect, maybe what makes sense is some classes to integrate Quartz into > Spring... I don't think there's an easy way to bring Quartz to Spring because Quartz requires you to implement a particular interface and go with its triggers. Also, it has its own events. But I don't want this to turn into a "battle" about Quartz. I plan to approach this issue from a point of view of Spring, make a list of functionality we may need (which will be easy since I am doing a project where this functionality will be required). Only after that we can discuss whether an existing package can be integrated. Or, perhaps, implementations could be pluggable. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-12 16:03:35
|
> In this > respect, maybe what makes sense is some classes to integrate Quartz into > Spring... > I plan to approach this issue from a point of view of Spring, make a list > of functionality we may need (which will be easy since I am doing > a project where this functionality will be required). Only after > that we can discuss whether an existing package can be integrated. Well, that's a good thing to do anyway. > Or, perhaps, implementations could be pluggable. I think that might be the best way to do things. We've done it with views and are doing it with persistence, so why not do it with schedulers as well... Alef ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rajeev K. <Ra...@cu...> - 2003-09-12 15:59:49
|
I agree. We should take advantage of existing open source projects that already implement this feature, and not re-invent the wheel. Here are couple of more resources that implement this feature: http://jcrontab.sourceforge.net http://jakarta.apache.org/turbine/index.html Rajeev Kaul ----- Original Message ----- From: "Colin Sampaleanu" <col...@ex...> To: "Ivan Ristic" <iv...@we...>; <spr...@li...> Sent: Friday, September 12, 2003 7:01 AM Subject: Re: [Springframework-developer] Spring scheduler? > Why not just take advantage of Quartz? It's free, and has an Apache/BSD > style license. > http://www.part.net/quartz.html > http://www.part.net/quartz_features.html > > We've been using it for a while with good results. Personally, I don't > think it's a great idea to add functionality to Spring which duplicates > existing projects that are out there and that have open licenses, > _unless_ the Spring implementation has some clear advantages. In this > respect, maybe what makes sense is some classes to integrate Quartz into > Spring... > > Regards, > Colin > > > Ivan Ristic wrote: > > > > > [Note: I sent this email yesterday but I did not see it arrive to > > the mailing list. So here is it again.] > > > > > > As part of my project I am building a (simple but capable) cron-like > > scheduler. Do you think there is a place for it in the Spring > > framework? It will support both persistent and non-persistent scheduling. > > > > I think the scheduler itself should be a JavaBean, capable of > > executing a given method (with or without parameters) on > > an object, according to the supplied schedule. > > > > Another possibility is to have the scheduler integrated into the > > context but I'm not sure how smart that would be. > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
