Menu
▾
▴
springframework-developer
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-12 17:29:56
|
> 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... > So, if we take that approach, the first thing would be to design a > "Scheduler" strategy interface which then could be implemented by different > "wrappers" around existing implementations. What everybody thinks? Exactly! But I think the list of requirements still needs to be made, reflecting people's experiences with schedulers... Alef |
|
From: Kopylenko, D. <dko...@ac...> - 2003-09-12 16:23:57
|
> 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... So, if we take that approach, the first thing would be to design a "Scheduler" strategy interface which then could be implemented by different "wrappers" around existing implementations. What everybody thinks? Regards, Dmitriy. |
|
From: Rod J. <rod...@in...> - 2003-09-13 10:05:51
|
Sounds good to me. ----- Original Message ----- From: "Kopylenko, Dmitry" <dko...@su...> To: <al...@jt...>; "'Ivan Ristic'" <iv...@we...>; "'Colin Sampaleanu'" <col...@ex...> Cc: <spr...@li...> Sent: Friday, September 12, 2003 5:23 PM Subject: RE: [Springframework-developer] Spring scheduler? > > 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... > > So, if we take that approach, the first thing would be to design a > "Scheduler" strategy interface which then could be implemented by different > "wrappers" around existing implementations. What everybody thinks? > > Regards, > Dmitriy. > > > > ------------------------------------------------------- > 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: <jue...@we...> - 2003-09-23 12:42:39
|
T24gcmVsYXRlZCB0ZXJtcywgSSdsbCB3b3JrIG9uIEoyRUUgaW50ZWdyYXRpb24gZm9yIFNCQidz IFVDNCBqb2Igc2NoZWR1bGluZyBzeXN0ZW0gaW4gT2N0b2Jlci4gVGhlcmUgaXMgZGVmaW5pdGVs eSBhIGxvdCBvZiBvdmVybGFwIGhlcmUsIGFuZCB0aGUgYmlnIHBsdXMgdGhhdCBTQkIgaGF2ZSBh Z3JlZWQgdG8gZGVmaW5lIGNvbW1vbiBwYXJ0cyBhbmQgaW50ZXJmYWNlcyBhcyBvcGVuIHNvdXJj ZSBwcm9qZWN0IGEgbGEgQU9QIEFsbGlhbmNlLiBHZW5lcmljIGludGVyZmFjZXMgYW5kIGRlZmlu aXRpb25zIGZvciBpbXBsZW1lbnRpbmcgam9icywgYW5kIGltcGxlbWVudGF0aW9ucyBmb3IgVUM0 IHZpYSBKQ0EvSk1TIGFuZCBmb3IgU3ByaW5nIGluIGEgYmVhbiBmYWN0b3J5IHN0eWxlLi4uIHNv dW5kcyBpbnRlcmVzdGluZyB0byBtZSA6LSkgQWRkaXRpb25hbGx5LCBTQkIgaGF2ZSBnb29kIHJl bGF0aW9ucyB3aXRoIFNBUCBhbmQgdGhlIG1ha2VycyBvZiBGbHV4LCBzbyB0aGVyZSBzaG91bGQg YmUgcGxlbnR5IG9mIGZlZWRiYWNrIGFuZCBjaGFuY2VzIGZvciBmdXR1cmUgZGV2ZWxvcG1lbnRz Lg0KIA0KSSdsbCBwcm92aWRlIG1vcmUgZGV0YWlscyB3aGVuIEknbSBiYWNrIGF0IHdvcmsgLSBh dCB0aGUgbW9tZW50LCBJJ20gc3RpbGwgaW4gQXVzdHJhbGlhLi4uDQogDQpKdWVyZ2VuDQogDQoN CgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBLb3B5bGVua28sIERtaXRyeSBb bWFpbHRvOmRrb3B5bGVua29AYWNzLnJ1dGdlcnMuZWR1XSANCglTZW50OiBGcmkgOS8xMi8yMDAz IDY6MjMgUE0gDQoJVG86ICdhbGVmQGp0ZWFtLm5sJzsgJ0l2YW4gUmlzdGljJzsgJ0NvbGluIFNh bXBhbGVhbnUnIA0KCUNjOiAnc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vm b3JnZS5uZXQnIA0KCVN1YmplY3Q6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gU3By aW5nIHNjaGVkdWxlcj8NCgkNCgkNCg0KCT4gSSB0aGluayB0aGF0IG1pZ2h0IGJlIHRoZSBiZXN0 IHdheSB0byBkbyB0aGluZ3MuIFdlJ3ZlIGRvbmUgaXQgd2l0aA0KCT4gdmlld3MgYW5kIGFyZSBk b2luZyBpdCB3aXRoIHBlcnNpc3RlbmNlLCBzbyB3aHkgbm90IGRvIGl0IHdpdGggc2NoZWR1bGVy cw0KCWFzIHdlbGwuLi4NCgkNCglTbywgaWYgd2UgdGFrZSB0aGF0IGFwcHJvYWNoLCB0aGUgZmly c3QgdGhpbmcgd291bGQgYmUgdG8gZGVzaWduIGENCgkiU2NoZWR1bGVyIiBzdHJhdGVneSBpbnRl cmZhY2Ugd2hpY2ggdGhlbiBjb3VsZCBiZSBpbXBsZW1lbnRlZCBieSBkaWZmZXJlbnQNCgkid3Jh cHBlcnMiIGFyb3VuZCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuIFdoYXQgZXZlcnlib2R5IHRo aW5rcz8NCgkNCglSZWdhcmRzLA0KCURtaXRyaXkuDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgc2YubmV0IGVt YWlsIGlzIHNwb25zb3JlZCBieTpUaGlua0dlZWsNCglXZWxjb21lIHRvIGdlZWsgaGVhdmVuLg0K CWh0dHA6Ly90aGlua2dlZWsuY29tL3NmDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlz dA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0 cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3Jr LWRldmVsb3Blcg0KCQ0KDQo= |
|
From: Ivan R. <iv...@we...> - 2003-09-24 14:30:31
|
jürgen höller [werk3AT] wrote: > On related terms, I'll work on J2EE integration for SBB's UC4 > job scheduling system in October. There is definitely a lot of > overlap here, and the big plus that SBB have agreed to define common > parts and interfaces as open source project a la AOP Alliance. Generic > interfaces and definitions for implementing jobs, and implementations > for UC4 via JCA/JMS and for Spring in a bean factory style... sounds > interesting to me :-) Additionally, SBB have good relations with SAP > and the makers of Flux, so there should be plenty of feedback and > chances for future developments. That's very good news. As far as I am concerned we can wait for that, especially since I moved my scheduler-related project for early next year. However, I did put some work toward this since our last email exchange and would like to proceed (slowly, as you can see) with it: I have reviewed Quartz and, now that I've invested time to learn how it works, I have no real desire to create a new scheduling library. I still find it too complex, though, but nothing is perfect. Therefore I am proposing what someone else proposed before, to create a simple Quartz wrapper. I also looked at the J2EE timer service and found it too simplistic. There is an interesting article on the subject: http://www2.theserverside.com/resources/article.jsp?l=MonsonHaefel-Column4 I've tried to create a very simple (as simple as it can be) scheduling wrapper and this is what I've come up with: ------------------------- public interface Scheduler { // schedule is cron-like scheduling formula public int createTask(String schedule, Runnable runnable); public boolean removeTask(int taskid); } public class SpringSchedulerHelper implements Scheduler { public int createTask(String schedule, String bean); public int createTask(String schedule, String bean, String method); public int createTask(String schedule, String bean, String method, String[] args); // these two are not specific to Spring, actually public int createTask(String schedule, Object instance, Method m); public int createTask(String schedule, Object instance, Method m, Object[] args); public int createTask(String schedule, ApplicationEvent event); // perhaps more createTask methods here // scheduler implementation set at runtime public void setScheduler(Scheduler scheduler); public void getScheduler(); } public class SpringTaskWrapper implements Runnable { // todo ... } -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Kopylenko, D. <dko...@ac...> - 2003-09-24 14:51:25
|
Perhaps SpringSchedulerHelper should not implement Scheduler, but use = it as underlying strategy ? Regards, Dmitriy. -----Original Message----- From: Ivan Ristic [mailto:iv...@we...]=20 Sent: Wednesday, September 24, 2003 10:28 AM To: "j=FCrgen h=F6ller [werk3AT]" Cc: Kopylenko, Dmitry; al...@jt...; Colin Sampaleanu; spr...@li... Subject: Re: [Springframework-developer] Spring scheduler? j=FCrgen h=F6ller [werk3AT] wrote: > On related terms, I'll work on J2EE integration for SBB's UC4 > job scheduling system in October. There is definitely a lot of > overlap here, and the big plus that SBB have agreed to define common=20 > parts and interfaces as open source project a la AOP Alliance. = Generic=20 > interfaces and definitions for implementing jobs, and implementations = > for UC4 via JCA/JMS and for Spring in a bean factory style... sounds=20 > interesting to me :-) Additionally, SBB have good relations with SAP=20 > and the makers of Flux, so there should be plenty of feedback and=20 > chances for future developments. That's very good news. As far as I am concerned we can wait for that, especially since I moved my scheduler-related project for early next year. However, I did put some work toward this since our last email exchange and would like to proceed (slowly, as you can see) with it: I have reviewed Quartz and, now that I've invested time to learn how it works, I have no real desire to create a new scheduling library. I still find it too complex, though, but nothing is perfect. Therefore I am proposing what someone else proposed before, to create a simple Quartz wrapper. I also looked at the J2EE timer service and found it too simplistic. There is an interesting article on the subject: =20 http://www2.theserverside.com/resources/article.jsp?l=3DMonsonHaefel-Col= umn4 I've tried to create a very simple (as simple as it can be) = scheduling wrapper and this is what I've come up with: ------------------------- public interface Scheduler { // schedule is cron-like scheduling formula public int createTask(String schedule, Runnable runnable); public boolean removeTask(int taskid); } public class SpringSchedulerHelper implements Scheduler { public int createTask(String schedule, String bean); public int createTask(String schedule, String bean, String = method); public int createTask(String schedule, String bean, String method, = String[] args); // these two are not specific to Spring, actually=09 public int createTask(String schedule, Object instance, Method m); public int createTask(String schedule, Object instance, Method m,=20 Object[] args); =09 public int createTask(String schedule, ApplicationEvent event); // perhaps more createTask methods here // scheduler implementation set at runtime public void setScheduler(Scheduler scheduler); public void getScheduler(); } public class SpringTaskWrapper implements Runnable { // todo ... } --=20 ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Ivan R. <iv...@we...> - 2003-09-24 15:07:13
|
Kopylenko, Dmitry wrote: > Perhaps SpringSchedulerHelper should not implement Scheduler, > but use it as underlying strategy ? Implementation is only formal, calls to methods from the Scheduler interface would be forwarded to the underlying strategy object. The benefit of this is that you only need to concern yourself with one object reference (when you are using a scheduler). -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
|
From: Ivan R. <iv...@we...> - 2003-09-12 19:28:10
|
> Exactly! But I think the list of requirements still needs to be made, > reflecting people's experiences with schedulers... My scheduler requirements are given below. These are based on the implementation I've started some time ago. This is not an attempt to define and replace an "enterprise scheduler". For a nice example of an enterprise class scheduler have a look at Flux, http://www.simscomputing.com/. Scheduler requirements ====================== Immediate --------- * Easy to use (gentle learning curve) * Non intrusive (any object method can be scheduled) * Support for persistent and non-persistent tasks * Crontab compatible syntax (see "man crontab") * Support for runnable interfaces * Support for any object method, with our without parameters * Spring support, scheduling directly from the configuration file * Spring support, events to be scheduled * Pluggable persistence modules * File system storage module (crontab compatible) * Changes to task data in the container will be picked up by the engine * Support for task launchers, eg, execute native binaries, RMI, EJB, XMLRPC, SOAP, etc. Other ----- * Support for seconds (crontab does not support resolution finer than minutes) * JDBC storage module * Misc. launcher implementations * Persisting information between tasks -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ] |
