Menu
▾
▴
springframework-developer
|
From: Dmitriy K. <dko...@ru...> - 2004-02-18 23:13:29
|
Nice feature! We might be able to utilize this=2E +1 from me=2E=2E=2E Regards=2C Dmitriy=2E ----- Original Message ----- From=3A j=C3=BCrgen h=C3=B6ller =5Bwerk3AT=5D =3Cjuergen=2Ehoeller=40werk= 3at=2Ecom=3E Date=3A Wednesday=2C February 18=2C 2004 5=3A43 pm Subject=3A =5BSpringframework-developer=5D Quartz support =3E Everybody=2C =3E = =3E I=27ve revived my Quartz support classes for Spring today=2E They = =3E emerged from a job scheduling consulting project I did in autumn = =3E 2003=2E We have concrete needs for this now at werk3AT=2C thus the = =3E revival=3A It=27s about quite simple cron-style scheduling of = =3E application jobs=2E =3E = =3E The basic idea is to set up a Quartz Scheduler via a = =3E SchedulerFactoryBean=2C also allowing to register scheduled jobs = =3E there via a =3Clist=3E of =3Crefs=3E to ScheduledJobDefinition beans=2E= A = =3E ScheduledJobDefinition is just a simple combination of a Quartz = =3E JobDetail and a Quartz Trigger=2E =3E = =3E ScheduledJobDefinition bean implementations include=3A =3E - DefaultScheduledJobDefinition=2C allowing to use any = =3E implementation of Quartz=27 Job interface with a declaratively = =3E configured job data map and cron trigger =3E - MethodInvokingJobDefinition=2C allowing to specify a method of a = =3E Spring-managed bean to execute as job (completely declarative=2C = =3E without the need for implementing a custom Job object)=2C with a = =3E cron trigger=2E =3E = =3E Both job definition beans can link in a separate Quartz Trigger = =3E instance instead of a cron expression=3B = =3E DefaultScheduledJobDefinition can also link in a separate Quartz = =3E JobDetail instance instead of a job class=2E =3E = =3E That=27s all there is=3A A simple declarative way of using Quartz = =3E within Spring=2E Typically no rescheduling or the like=3A All = =3E schedules are set up on context startup=2C defined as bean = =3E definitions=2E Of course=2C you can also fetch the Scheduler instance= = =3E and perform any custom scheduling=2C instead of using preconfigured = =3E ScheduledJobDefinition beans=2E =3E = =3E The typical usage scenario are low-level jobs within an = =3E application=2C like data synchronization or storage cleanup - all = =3E predefined jobs that are just customized by an administrator=2E Fits = =3E nicely into Spring=27s application context model=3B most jobs will = =3E simply delegate to Spring-managed business objects=2E =3E = =3E I expect to have this polished by the end of the week=2C as we need = =3E it at werk3AT quite urgently=2E I=27d like to include this already in= = =3E Spring 1=2E0 final=2C as it=27s just 6 pretty simple classes (yes=2C = I = =3E know - feature freeze - never mind =3B-)=2E The main question is wher= e = =3E to put it=3A I suggest =22org=2Espringframework=2Escheduling=2Equartz= =22=2E =3E = =3E If there are no general objections=2C I=27ll commit it by the end of = =3E this week=2C for review within the next week - still plenty of time = =3E before 1=2E0 final =3B-) Looking forward to your feedback! = =3E = =3E Juergen =3E = =3E = =3E = =3E ------------------------------------------------------- =3E SF=2ENet is sponsored by=3A Speed Start Your Linux Apps Now=2E =3E Build and deploy apps =26 Web services for Linux with =3E a free DVD software kit from IBM=2E Click Now! =3E http=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=1356=26alloc=5Fid438=26op=3Dclic= k =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E Springframework-developer mailing list =3E Springframework-developer=40lists=2Esourceforge=2Enet =3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de= veloper =3E |
|
From: Ou, R. <Ro...@sa...> - 2004-02-18 23:26:40
|
This would be actually quite useful to us too. +1 Rong > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] > On Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Wednesday, February 18, 2004 4:43 PM > To: spr...@li... > Subject: [Springframework-developer] Quartz support >=20 >=20 > Everybody, > =20 > I've revived my Quartz support classes for Spring today. They=20 > emerged from a job scheduling consulting project I did in=20 > autumn 2003. We have concrete needs for this now at werk3AT,=20 > thus the revival: It's about quite simple cron-style=20 > scheduling of application jobs. > =20 > The basic idea is to set up a Quartz Scheduler via a=20 > SchedulerFactoryBean, also allowing to register scheduled=20 > jobs there via a <list> of <refs> to ScheduledJobDefinition=20 > beans. A ScheduledJobDefinition is just a simple combination=20 > of a Quartz JobDetail and a Quartz Trigger. > =20 > ScheduledJobDefinition bean implementations include: > - DefaultScheduledJobDefinition, allowing to use any=20 > implementation of Quartz' Job interface with a declaratively=20 > configured job data map and cron trigger > - MethodInvokingJobDefinition, allowing to specify a method=20 > of a Spring-managed bean to execute as job (completely=20 > declarative, without the need for implementing a custom Job=20 > object), with a cron trigger. > =20 > Both job definition beans can link in a separate Quartz=20 > Trigger instance instead of a cron expression;=20 > DefaultScheduledJobDefinition can also link in a separate=20 > Quartz JobDetail instance instead of a job class. > =20 > That's all there is: A simple declarative way of using Quartz=20 > within Spring. Typically no rescheduling or the like: All=20 > schedules are set up on context startup, defined as bean=20 > definitions. Of course, you can also fetch the Scheduler=20 > instance and perform any custom scheduling, instead of using=20 > preconfigured ScheduledJobDefinition beans. > =20 > The typical usage scenario are low-level jobs within an=20 > application, like data synchronization or storage cleanup -=20 > all predefined jobs that are just customized by an=20 > administrator. Fits nicely into Spring's application context=20 > model; most jobs will simply delegate to Spring-managed=20 > business objects. > =20 > I expect to have this polished by the end of the week, as we=20 > need it at werk3AT quite urgently. I'd like to include this=20 > already in Spring 1.0 final, as it's just 6 pretty simple=20 > classes (yes, I know - feature freeze - never mind ;-). The=20 > main question is where to put it: I suggest=20 > "org.springframework.scheduling.quartz". > =20 > If there are no general objections, I'll commit it by the end=20 > of this week, for review within the next week - still plenty=20 > of time before 1.0 final ;-) Looking forward to your feedback!=20 > =20 > Juergen > =20 >=20 >=20 > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 |
|
From: <jue...@we...> - 2004-02-19 15:59:41
|
Daniel,
As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.
However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
The Quartz support classes (to be committed within an hour!) provide the =
following:
- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
A configuration example:
<bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
<property name=3D"triggers">
<list>
<ref bean=3D"myTrigger1"/>
<ref bean=3D"myTrigger2"/>
</list>
</property>
</bean>
<bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
<property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
<property name=3D"jobDataAsMap">
<map>
<entry key=3D"testBean">
<bean class=3D"org.springframework.beans.TestBean">
<property name=3D"age"><value>99</value></property>
</bean>
</entry>
</map>
</property>
</bean>
<bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
<property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
<property name=3D"targetMethod"><value>doSomething</value></property>
</bean>
<bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
<property name=3D"jobDetail"><ref bean=3D"myJobDetail1"/></property>
<property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
</bean>
<bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
<property name=3D"jobDetail"><ref bean=3D"myJobDetail2"/></property>
<property name=3D"repeatInterval"><value>1000</value></property>
</bean>
MyJob (as referenced from "myJobDetail1") can be implemented as follows:
public static class MyJob extends QuartzJobBean {
private TestBean testBean;
public void setTestBean(TestBean testBean) {
this.testBean =3D testBean;
}
protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
System.out.println("Executing job..." + testBean.getAge());
}
}
Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Daniel Potter
Sent: Thursday, February 19, 2004 4:17 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Quartz support
Juergen,
I have a question regarding these classes and/or your general experience
using Quartz with Spring in an J2EE container. We've run into JNDI
lookup issues with jobs that attempt to use Spring beans that contain
references to JNDI resources (thru a JndiObjectFactoryBean). It appears
the Quartz job doesn't know it's running within the container (even
though the scheduler is started in the init() method of a servlet), so =
it's
dependencies fail to locate the default JNDI context (and therefore fail
to locate their JNDI dependencies). I assume this is because the
scheduler is running in its own thread, so it doesn't have any implicit
knowledge of the container. To get around this, we've been
forced to use a separate Spring config file for the Quartz jobs that
overrides the default JNDI settings used by the JndiObjectFactoryBean
like this (as if the job had to connect to JNDI remotely):
<!-- JNDI connection information -->
<bean id=3D"myJndiTemplate"
class=3D"org.springframework.jndi.JndiTemplate">
<property name=3D"environment">
<props>
<prop
key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialCo=
ntextFactory</prop>
<prop
key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
<prop key=3D"java.naming.security.credentials">user</prop>
<prop key=3D"java.naming.security.principal">pw</prop>
</props>
</property>
</bean>
<!-- QUEUE CONNECTION FACTORY -->
<bean id=3D"jmsQueueConnectionFactory"
class=3D"org.springframework.jndi.JndiObjectFactoryBean"
lazy-init=3D"true">
<property name=3D"inContainer">
<value>false</value>
</property>
<property name=3D"jndiTemplate">
<ref local=3D"myJndiTemplate"/>
</property>
<property name=3D"jndiName">
<value>Example/QueueConnectionFactory</value>
</property>
</bean>
This also requires us to load a separate application context for the
Quartz jobs that uses these settings, rather than being able to share
the application context used by the rest of the application.
=20
Have you ever run into this issue? Do your support classes get around
this somehow?
Regards,
Daniel
On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] wrote:
> Everybody,
> =20
> I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
> =20
> The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
> =20
> ScheduledJobDefinition bean implementations include:
> - DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and =
cron trigger
> - MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
> =20
> Both job definition beans can link in a separate Quartz Trigger =
instance instead of a cron expression; DefaultScheduledJobDefinition can =
also link in a separate Quartz JobDetail instance instead of a job =
class.
> =20
> That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
> =20
> The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
> =20
> I expect to have this polished by the end of the week, as we need it =
at werk3AT quite urgently. I'd like to include this already in Spring =
1.0 final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
> =20
> If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!=20
> =20
> Juergen
> =20
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Daniel P. <po...@ci...> - 2004-02-19 17:15:53
|
Juergen,
We'll give your strategy a shot when we get a chance. Sounds like it
should work. I'll be sure to respond to this list with the results.
Thanks for your help!
Daniel
On Thu, Feb 19, 2004 at 04:54:18PM +0100, j?rgen h?ller [werk3AT] wrote:
> Daniel,
>=20
> As you say, this is most likely caused by the fact that Quartz uses its o=
wn threads. WebSphere seems to associate the JNDI context information with =
container-managed threads; unfortunately, this does not apply to Quartz thr=
eads.
>=20
> However, there's a strategy that should work: pre-locate the JNDI objects=
, and pass the objects to Quartz' job data map. This way, the Quartz job sh=
ould receive the pre-located objects when running in its own thread, not ne=
eding to do a JNDI lookup itself.
>=20
> The Quartz support classes (to be committed within an hour!) provide the =
following:
>=20
> - a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to reg=
ister JobDetails, Calendars and Triggers with it
>=20
> - convenience subclasses of JobDetail, CronTrigger and SimpleTrigger that=
allow for easy bean-style usage; the latter allow for implicit registratio=
n of an associated JobDetail
>=20
> - a FactoryBean for a JobDetail that invokes a method of an existing obje=
ct, to avoid the need for writing one-line Job implementations that just de=
legate to a business method
>=20
> - a convenience implementation of Quartz' Job interface, applying job dat=
a map entries as bean properties
>=20
> A configuration example:
>=20
> <bean id=3D"scheduler" class=3D"org.springframework.scheduling.quartz.Sc=
hedulerFactoryBean">
> <property name=3D"triggers">
> <list>
> <ref bean=3D"myTrigger1"/>
> <ref bean=3D"myTrigger2"/>
> </list>
> </property>
> </bean>
>=20
> <bean id=3D"myJobDetail1" class=3D"org.springframework.scheduling.quartz=
.JobDetailBean">
> <property name=3D"jobClass"><value>werk3.example.MyJob</value></propert=
y>
> <property name=3D"jobDataAsMap">
> <map>
> <entry key=3D"testBean">
> <bean class=3D"org.springframework.beans.TestBean">
> <property name=3D"age"><value>99</value></property>
> </bean>
> </entry>
> </map>
> </property>
> </bean>
>=20
> <bean id=3D"myJobDetail2" class=3D"org.springframework.scheduling.quartz=
.MethodInvokingJobDetailFactoryBean">
> <property name=3D"targetObject"><ref bean=3D"exampleService"/></propert=
y>
> <property name=3D"targetMethod"><value>doSomething</value></property>
> </bean>
>=20
> <bean id=3D"myTrigger1" class=3D"org.springframework.scheduling.quartz.C=
ronTriggerBean">
> <property name=3D"jobDetail"><ref bean=3D"myJobDetail1"/></property>
> <property name=3D"cronExpression"><value>0/5 * * * * ?</value></propert=
y>
> </bean>
>=20
> <bean id=3D"myTrigger2" class=3D"org.springframework.scheduling.quartz.S=
impleTriggerBean">
> <property name=3D"jobDetail"><ref bean=3D"myJobDetail2"/></property>
> <property name=3D"repeatInterval"><value>1000</value></property>
> </bean>
>=20
> MyJob (as referenced from "myJobDetail1") can be implemented as follows:
>=20
> public static class MyJob extends QuartzJobBean {
>=20
> private TestBean testBean;
>=20
> public void setTestBean(TestBean testBean) {
> this.testBean =3D testBean;
> }
>=20
> protected void executeInternal(JobExecutionContext jobExecutionContext)=
{
> System.out.println("Executing job..." + testBean.getAge());
> }
> }
>=20
> Note that the "testBean" entry in the job data map is automatically appli=
ed as bean property in MyJob.
>=20
> As a side note, I've refactored Colin's MethodInvokingFactoryBean into or=
g.springframework.util.MethodInvoker, with MethodInvokingFactoryBean and Me=
thodInvokingJobDetailFactoryBean as subclasses. They provide exactly the sa=
me invocation capabilities.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Daniel Potter
> Sent: Thursday, February 19, 2004 4:17 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Quartz support
>=20
>=20
> Juergen,
> I have a question regarding these classes and/or your general experience
> using Quartz with Spring in an J2EE container. We've run into JNDI
> lookup issues with jobs that attempt to use Spring beans that contain
> references to JNDI resources (thru a JndiObjectFactoryBean). It appears
> the Quartz job doesn't know it's running within the container (even
> though the scheduler is started in the init() method of a servlet), so it=
's
> dependencies fail to locate the default JNDI context (and therefore fail
> to locate their JNDI dependencies). I assume this is because the
> scheduler is running in its own thread, so it doesn't have any implicit
> knowledge of the container. To get around this, we've been
> forced to use a separate Spring config file for the Quartz jobs that
> overrides the default JNDI settings used by the JndiObjectFactoryBean
> like this (as if the job had to connect to JNDI remotely):
>=20
> <!-- JNDI connection information -->
> <bean id=3D"myJndiTemplate"
> class=3D"org.springframework.jndi.JndiTemplate">
> <property name=3D"environment">
> <props>
> <prop
> key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialCo=
ntextFactory</prop>
> <prop
> key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
> <prop key=3D"java.naming.security.credentials">user</prop>
> <prop key=3D"java.naming.security.principal">pw</prop>
> </props>
> </property>
> </bean>
>=20
> <!-- QUEUE CONNECTION FACTORY -->
> <bean id=3D"jmsQueueConnectionFactory"
> class=3D"org.springframework.jndi.JndiObjectFactoryBean"
> lazy-init=3D"true">
> <property name=3D"inContainer">
> <value>false</value>
> </property>
> <property name=3D"jndiTemplate">
> <ref local=3D"myJndiTemplate"/>
> </property>
> <property name=3D"jndiName">
> <value>Example/QueueConnectionFactory</value>
> </property>
> </bean>
>=20
> This also requires us to load a separate application context for the
> Quartz jobs that uses these settings, rather than being able to share
> the application context used by the rest of the application.
> =20
> Have you ever run into this issue? Do your support classes get around
> this somehow?
>=20
> Regards,
> Daniel
>=20
> On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] wrote:
> > Everybody,
> > =20
> > I've revived my Quartz support classes for Spring today. They emerged f=
rom a job scheduling consulting project I did in autumn 2003. We have concr=
ete needs for this now at werk3AT, thus the revival: It's about quite simpl=
e cron-style scheduling of application jobs.
> > =20
> > The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBe=
an, also allowing to register scheduled jobs there via a <list> of <refs> t=
o ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simple c=
ombination of a Quartz JobDetail and a Quartz Trigger.
> > =20
> > ScheduledJobDefinition bean implementations include:
> > - DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and cron=
trigger
> > - MethodInvokingJobDefinition, allowing to specify a method of a Spring=
-managed bean to execute as job (completely declarative, without the need f=
or implementing a custom Job object), with a cron trigger.
> > =20
> > Both job definition beans can link in a separate Quartz Trigger instanc=
e instead of a cron expression; DefaultScheduledJobDefinition can also link=
in a separate Quartz JobDetail instance instead of a job class.
> > =20
> > That's all there is: A simple declarative way of using Quartz within Sp=
ring. Typically no rescheduling or the like: All schedules are set up on co=
ntext startup, defined as bean definitions. Of course, you can also fetch t=
he Scheduler instance and perform any custom scheduling, instead of using p=
reconfigured ScheduledJobDefinition beans.
> > =20
> > The typical usage scenario are low-level jobs within an application, li=
ke data synchronization or storage cleanup - all predefined jobs that are j=
ust customized by an administrator. Fits nicely into Spring's application c=
ontext model; most jobs will simply delegate to Spring-managed business obj=
ects.
> > =20
> > I expect to have this polished by the end of the week, as we need it at=
werk3AT quite urgently. I'd like to include this already in Spring 1.0 fin=
al, as it's just 6 pretty simple classes (yes, I know - feature freeze - ne=
ver mind ;-). The main question is where to put it: I suggest "org.springfr=
amework.scheduling.quartz".
> > =20
> > If there are no general objections, I'll commit it by the end of this w=
eek, for review within the next week - still plenty of time before 1.0 fina=
l ;-) Looking forward to your feedback!=20
> > =20
> > Juergen
> > =20
> >=20
> >=20
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-02-19 20:46:23
|
The Quartz support is already in CVS, and also in use within the werk3AT =
app it was intended for... feel free to check it out!
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 19.02.2004 16:54
An: spr...@li...
Betreff: RE: [Springframework-developer] Quartz support
Daniel,
As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.
However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
The Quartz support classes (to be committed within an hour!) provide the =
following:
- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
A configuration example:
<bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
<property name=3D"triggers">
<list>
<ref bean=3D"myTrigger1"/>
<ref bean=3D"myTrigger2"/>
</list>
</property>
</bean>
<bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
<property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
<property name=3D"jobDataAsMap">
<map>
<entry key=3D"testBean">
<bean =
class=3D"org.springframework.beans.TestBean">
<property =
name=3D"age"><value>99</value></property>
</bean>
</entry>
</map>
</property>
</bean>
<bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
<property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
<property =
name=3D"targetMethod"><value>doSomething</value></property>
</bean>
<bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
<property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
<property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
</bean>
<bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
<property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
<property =
name=3D"repeatInterval"><value>1000</value></property>
</bean>
MyJob (as referenced from "myJobDetail1") can be implemented as follows:
public static class MyJob extends QuartzJobBean {
private TestBean testBean;
public void setTestBean(TestBean testBean) {
this.testBean =3D testBean;
}
protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
System.out.println("Executing job..." + =
testBean.getAge());
}
}
Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Daniel Potter
Sent: Thursday, February 19, 2004 4:17 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Quartz support
Juergen,
I have a question regarding these classes and/or your general experience
using Quartz with Spring in an J2EE container. We've run into JNDI
lookup issues with jobs that attempt to use Spring beans that contain
references to JNDI resources (thru a JndiObjectFactoryBean). It appears
the Quartz job doesn't know it's running within the container (even
though the scheduler is started in the init() method of a servlet), so =
it's
dependencies fail to locate the default JNDI context (and therefore fail
to locate their JNDI dependencies). I assume this is because the
scheduler is running in its own thread, so it doesn't have any implicit
knowledge of the container. To get around this, we've been
forced to use a separate Spring config file for the Quartz jobs that
overrides the default JNDI settings used by the JndiObjectFactoryBean
like this (as if the job had to connect to JNDI remotely):
<!-- JNDI connection information -->
<bean id=3D"myJndiTemplate"
class=3D"org.springframework.jndi.JndiTemplate">
<property name=3D"environment">
<props>
<prop
key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialCo=
ntextFactory</prop>
<prop
key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
<prop key=3D"java.naming.security.credentials">user</prop>
<prop key=3D"java.naming.security.principal">pw</prop>
</props>
</property>
</bean>
<!-- QUEUE CONNECTION FACTORY -->
<bean id=3D"jmsQueueConnectionFactory"
class=3D"org.springframework.jndi.JndiObjectFactoryBean"
lazy-init=3D"true">
<property name=3D"inContainer">
<value>false</value>
</property>
<property name=3D"jndiTemplate">
<ref local=3D"myJndiTemplate"/>
</property>
<property name=3D"jndiName">
<value>Example/QueueConnectionFactory</value>
</property>
</bean>
This also requires us to load a separate application context for the
Quartz jobs that uses these settings, rather than being able to share
the application context used by the rest of the application.
Have you ever run into this issue? Do your support classes get around
this somehow?
Regards,
Daniel
On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] wrote:
> Everybody,
>=20
> I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
>=20
> The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
>=20
> ScheduledJobDefinition bean implementations include:
> - DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and =
cron trigger
> - MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
>=20
> Both job definition beans can link in a separate Quartz Trigger =
instance instead of a cron expression; DefaultScheduledJobDefinition can =
also link in a separate Quartz JobDetail instance instead of a job =
class.
>=20
> That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
>=20
> The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
>=20
> I expect to have this polished by the end of the week, as we need it =
at werk3AT quite urgently. I'd like to include this already in Spring =
1.0 final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
>=20
> If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!
>=20
> Juergen
>=20
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Colin S. <col...@ex...> - 2004-02-19 21:00:42
|
Hey Juergen,
The Quartz stuff looks like good stuff on an initial lookover.
I do have a comment about your refactoring of MethodInvokingFactoryBean.
For the static method call case, your refactoring is arguably cleaner=20
because the same property is used for specifyng the method name as for=20
the non-static case, but on the other hand, static methods are probably=20
one of the most common uses of this class, and you've turned a one=20
property config into a two property config, i.e.
<bean id=3D"qa-util-initProfileImpl"=20
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
<property=20
name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClassesI=
nit.initProfileClasses</value></property>
</bean>
tnow becomes
<bean id=3D"qa-util-initProfileImpl"=20
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
<property=20
name=3D"targetMethod"><value>initProfileClasses</value></property>
<property=20
name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesIn=
it</value></property>
</bean>
As well, this also breaks backwards compatibility for anybody using it.=20
Perhaps you can add back the
staticMethod
property, and on a set, the code inside it would break up the supplied=20
string into calls to setTargetMethod and setTargetClass (it would have=20
to create the class itself).
This would allow both forms to be used, and keep backwards compatibility.=
..
Regards,
Colin
j=FCrgen h=F6ller [werk3AT] wrote:
>The Quartz support is already in CVS, and also in use within the werk3AT=
app it was intended for... feel free to check it out!
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n j=FCrgen h=F6ller [werk3AT]
>Gesendet: Do 19.02.2004 16:54
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Quartz support
>
>
>
>Daniel,
>
>As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information wi=
th container-managed threads; unfortunately, this does not apply to Quart=
z threads.
>
>However, there's a strategy that should work: pre-locate the JNDI object=
s, and pass the objects to Quartz' job data map. This way, the Quartz job=
should receive the pre-located objects when running in its own thread, n=
ot needing to do a JNDI lookup itself.
>
>The Quartz support classes (to be committed within an hour!) provide the=
following:
>
>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to re=
gister JobDetails, Calendars and Triggers with it
>
>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger tha=
t allow for easy bean-style usage; the latter allow for implicit registra=
tion of an associated JobDetail
>
>- a FactoryBean for a JobDetail that invokes a method of an existing obj=
ect, to avoid the need for writing one-line Job implementations that just=
delegate to a business method
>
>- a convenience implementation of Quartz' Job interface, applying job da=
ta map entries as bean properties
>
>A configuration example:
>
> <bean id=3D"scheduler" class=3D"org.springframework.scheduling.q=
uartz.SchedulerFactoryBean">
> <property name=3D"triggers">
> <list>
> <ref bean=3D"myTrigger1"/>
> <ref bean=3D"myTrigger2"/>
> </list>
> </property>
> </bean>
>
> <bean id=3D"myJobDetail1" class=3D"org.springframework.schedulin=
g.quartz.JobDetailBean">
> <property name=3D"jobClass"><value>werk3.example.MyJob</=
value></property>
> <property name=3D"jobDataAsMap">
> <map>
> <entry key=3D"testBean">
> <bean class=3D"org.springframewo=
rk.beans.TestBean">
> <property name=3D"age"><=
value>99</value></property>
> </bean>
> </entry>
> </map>
> </property>
> </bean>
>
> <bean id=3D"myJobDetail2" class=3D"org.springframework.schedulin=
g.quartz.MethodInvokingJobDetailFactoryBean">
> <property name=3D"targetObject"><ref bean=3D"exampleServ=
ice"/></property>
> <property name=3D"targetMethod"><value>doSomething</valu=
e></property>
> </bean>
>
> <bean id=3D"myTrigger1" class=3D"org.springframework.scheduling.=
quartz.CronTriggerBean">
> <property name=3D"jobDetail"><ref bean=3D"myJobDetail1"/=
></property>
> <property name=3D"cronExpression"><value>0/5 * * * * ?</=
value></property>
> </bean>
>
> <bean id=3D"myTrigger2" class=3D"org.springframework.scheduling.=
quartz.SimpleTriggerBean">
> <property name=3D"jobDetail"><ref bean=3D"myJobDetail2"/=
></property>
> <property name=3D"repeatInterval"><value>1000</value></p=
roperty>
> </bean>
>
>MyJob (as referenced from "myJobDetail1") can be implemented as follows:
>
> public static class MyJob extends QuartzJobBean {
>
> private TestBean testBean;
>
> public void setTestBean(TestBean testBean) {
> this.testBean =3D testBean;
> }
>
> protected void executeInternal(JobExecutionContext jobEx=
ecutionContext) {
> System.out.println("Executing job..." + testBean=
.getAge());
> }
> }
>
>Note that the "testBean" entry in the job data map is automatically appl=
ied as bean property in MyJob.
>
>As a side note, I've refactored Colin's MethodInvokingFactoryBean into o=
rg.springframework.util.MethodInvoker, with MethodInvokingFactoryBean and=
MethodInvokingJobDetailFactoryBean as subclasses. They provide exactly t=
he same invocation capabilities.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Daniel Potter
>Sent: Thursday, February 19, 2004 4:17 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Quartz support
>
>
>Juergen,
>I have a question regarding these classes and/or your general experience
>using Quartz with Spring in an J2EE container. We've run into JNDI
>lookup issues with jobs that attempt to use Spring beans that contain
>references to JNDI resources (thru a JndiObjectFactoryBean). It appears
>the Quartz job doesn't know it's running within the container (even
>though the scheduler is started in the init() method of a servlet), so i=
t's
>dependencies fail to locate the default JNDI context (and therefore fail
>to locate their JNDI dependencies). I assume this is because the
>scheduler is running in its own thread, so it doesn't have any implicit
>knowledge of the container. To get around this, we've been
>forced to use a separate Spring config file for the Quartz jobs that
>overrides the default JNDI settings used by the JndiObjectFactoryBean
>like this (as if the job had to connect to JNDI remotely):
>
> <!-- JNDI connection information -->
> <bean id=3D"myJndiTemplate"
>class=3D"org.springframework.jndi.JndiTemplate">
> <property name=3D"environment">
> <props>
> <prop
>key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialC=
ontextFactory</prop>
> <prop
>key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
> <prop key=3D"java.naming.security.credentials">user</prop>
> <prop key=3D"java.naming.security.principal">pw</prop>
> </props>
> </property>
> </bean>
>
> <!-- QUEUE CONNECTION FACTORY -->
> <bean id=3D"jmsQueueConnectionFactory"
> class=3D"org.springframework.jndi.JndiObjectFactoryBean"
> lazy-init=3D"true">
> <property name=3D"inContainer">
> <value>false</value>
> </property>
> <property name=3D"jndiTemplate">
> <ref local=3D"myJndiTemplate"/>
> </property>
> <property name=3D"jndiName">
> <value>Example/QueueConnectionFactory</value>
> </property>
> </bean>
>
>This also requires us to load a separate application context for the
>Quartz jobs that uses these settings, rather than being able to share
>the application context used by the rest of the application.
>
>Have you ever run into this issue? Do your support classes get around
>this somehow?
>
>Regards,
>Daniel
>
>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] wrote:
> =20
>
>>Everybody,
>>
>>I've revived my Quartz support classes for Spring today. They emerged f=
rom a job scheduling consulting project I did in autumn 2003. We have con=
crete needs for this now at werk3AT, thus the revival: It's about quite s=
imple cron-style scheduling of application jobs.
>>
>>The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBe=
an, also allowing to register scheduled jobs there via a <list> of <refs>=
to ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simp=
le combination of a Quartz JobDetail and a Quartz Trigger.
>>
>>ScheduledJobDefinition bean implementations include:
>>- DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and cr=
on trigger
>>- MethodInvokingJobDefinition, allowing to specify a method of a Spring=
-managed bean to execute as job (completely declarative, without the need=
for implementing a custom Job object), with a cron trigger.
>>
>>Both job definition beans can link in a separate Quartz Trigger instanc=
e instead of a cron expression; DefaultScheduledJobDefinition can also li=
nk in a separate Quartz JobDetail instance instead of a job class.
>>
>>That's all there is: A simple declarative way of using Quartz within Sp=
ring. Typically no rescheduling or the like: All schedules are set up on =
context startup, defined as bean definitions. Of course, you can also fet=
ch the Scheduler instance and perform any custom scheduling, instead of u=
sing preconfigured ScheduledJobDefinition beans.
>>
>>The typical usage scenario are low-level jobs within an application, li=
ke data synchronization or storage cleanup - all predefined jobs that are=
just customized by an administrator. Fits nicely into Spring's applicati=
on context model; most jobs will simply delegate to Spring-managed busine=
ss objects.
>>
>>I expect to have this polished by the end of the week, as we need it at=
werk3AT quite urgently. I'd like to include this already in Spring 1.0 f=
inal, as it's just 6 pretty simple classes (yes, I know - feature freeze =
- never mind ;-). The main question is where to put it: I suggest "org.sp=
ringframework.scheduling.quartz".
>>
>>If there are no general objections, I'll commit it by the end of this w=
eek, for review within the next week - still plenty of time before 1.0 fi=
nal ;-) Looking forward to your feedback!
>>
>>Juergen
>> =20
>>
|
|
From: <jue...@we...> - 2004-02-19 21:15:30
|
Good point - I'll re-add "staticMethod" as convenience setter!
=20
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Do 19.02.2004 21:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support
Hey Juergen,
The Quartz stuff looks like good stuff on an initial lookover.
I do have a comment about your refactoring of MethodInvokingFactoryBean.
For the static method call case, your refactoring is arguably cleaner
because the same property is used for specifyng the method name as for
the non-static case, but on the other hand, static methods are probably
one of the most common uses of this class, and you've turned a one
property config into a two property config, i.e.
<bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
<property
name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClassesI=
nit.initProfileClasses</value></property>
</bean>
tnow becomes
<bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
<property
name=3D"targetMethod"><value>initProfileClasses</value></property>
<property
name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesIn=
it</value></property>
</bean>
As well, this also breaks backwards compatibility for anybody using it.
Perhaps you can add back the
staticMethod
property, and on a set, the code inside it would break up the supplied
string into calls to setTargetMethod and setTargetClass (it would have
to create the class itself).
This would allow both forms to be used, and keep backwards =
compatibility...
Regards,
Colin
j=FCrgen h=F6ller [werk3AT] wrote:
>The Quartz support is already in CVS, and also in use within the =
werk3AT app it was intended for... feel free to check it out!
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Do 19.02.2004 16:54
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Quartz support
>
>
>
>Daniel,
>
>As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.
>
>However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
>
>The Quartz support classes (to be committed within an hour!) provide =
the following:
>
>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
>
>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
>
>- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
>
>- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
>
>A configuration example:
>
> <bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
> <property name=3D"triggers">
> <list>
> <ref bean=3D"myTrigger1"/>
> <ref bean=3D"myTrigger2"/>
> </list>
> </property>
> </bean>
>
> <bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
> <property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
> <property name=3D"jobDataAsMap">
> <map>
> <entry key=3D"testBean">
> <bean =
class=3D"org.springframework.beans.TestBean">
> <property =
name=3D"age"><value>99</value></property>
> </bean>
> </entry>
> </map>
> </property>
> </bean>
>
> <bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
> <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
> <property =
name=3D"targetMethod"><value>doSomething</value></property>
> </bean>
>
> <bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
> <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
> <property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
> </bean>
>
> <bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
> <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
> <property =
name=3D"repeatInterval"><value>1000</value></property>
> </bean>
>
>MyJob (as referenced from "myJobDetail1") can be implemented as =
follows:
>
> public static class MyJob extends QuartzJobBean {
>
> private TestBean testBean;
>
> public void setTestBean(TestBean testBean) {
> this.testBean =3D testBean;
> }
>
> protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
> System.out.println("Executing job..." + =
testBean.getAge());
> }
> }
>
>Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
>
>As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Daniel Potter
>Sent: Thursday, February 19, 2004 4:17 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Quartz support
>
>
>Juergen,
>I have a question regarding these classes and/or your general =
experience
>using Quartz with Spring in an J2EE container. We've run into JNDI
>lookup issues with jobs that attempt to use Spring beans that contain
>references to JNDI resources (thru a JndiObjectFactoryBean). It =
appears
>the Quartz job doesn't know it's running within the container (even
>though the scheduler is started in the init() method of a servlet), so =
it's
>dependencies fail to locate the default JNDI context (and therefore =
fail
>to locate their JNDI dependencies). I assume this is because the
>scheduler is running in its own thread, so it doesn't have any implicit
>knowledge of the container. To get around this, we've been
>forced to use a separate Spring config file for the Quartz jobs that
>overrides the default JNDI settings used by the JndiObjectFactoryBean
>like this (as if the job had to connect to JNDI remotely):
>
> <!-- JNDI connection information -->
> <bean id=3D"myJndiTemplate"
>class=3D"org.springframework.jndi.JndiTemplate">
> <property name=3D"environment">
> <props>
> <prop
>key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialC=
ontextFactory</prop>
> <prop
>key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
> <prop key=3D"java.naming.security.credentials">user</prop>
> <prop key=3D"java.naming.security.principal">pw</prop>
> </props>
> </property>
> </bean>
>
> <!-- QUEUE CONNECTION FACTORY -->
> <bean id=3D"jmsQueueConnectionFactory"
> class=3D"org.springframework.jndi.JndiObjectFactoryBean"
> lazy-init=3D"true">
> <property name=3D"inContainer">
> <value>false</value>
> </property>
> <property name=3D"jndiTemplate">
> <ref local=3D"myJndiTemplate"/>
> </property>
> <property name=3D"jndiName">
> <value>Example/QueueConnectionFactory</value>
> </property>
> </bean>
>
>This also requires us to load a separate application context for the
>Quartz jobs that uses these settings, rather than being able to share
>the application context used by the rest of the application.
>
>Have you ever run into this issue? Do your support classes get around
>this somehow?
>
>Regards,
>Daniel
>
>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] =
wrote:
>=20
>
>>Everybody,
>>
>>I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
>>
>>The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
>>
>>ScheduledJobDefinition bean implementations include:
>>- DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and =
cron trigger
>>- MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
>>
>>Both job definition beans can link in a separate Quartz Trigger =
instance instead of a cron expression; DefaultScheduledJobDefinition can =
also link in a separate Quartz JobDetail instance instead of a job =
class.
>>
>>That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
>>
>>The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
>>
>>I expect to have this polished by the end of the week, as we need it =
at werk3AT quite urgently. I'd like to include this already in Spring =
1.0 final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
>>
>>If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!
>>
>>Juergen
>> =20
>>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Colin S. <col...@ex...> - 2004-02-25 04:23:56
|
Juergen,
Further to this, I noticed you changed the 'args' property to 'arguments'. For me personally this is not that big a deal (I've alrady made the change in my configs), but do you think it's really worth breaking backwards compatibility for this? Args is a well known and used abbreviation for arguments. I wouldn't say the latter is so much better than the former that it's worth breaking people's config, now that the code already shipped with the name args...
Regards,
Colin
jürgen höller [werk3AT] wrote:
>Good point - I'll re-add "staticMethod" as convenience setter!
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Do 19.02.2004 21:54
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Quartz support
>
>
>
>Hey Juergen,
>
>The Quartz stuff looks like good stuff on an initial lookover.
>
>I do have a comment about your refactoring of MethodInvokingFactoryBean.
>
>For the static method call case, your refactoring is arguably cleaner
>because the same property is used for specifyng the method name as for
>the non-static case, but on the other hand, static methods are probably
>one of the most common uses of this class, and you've turned a one
>property config into a two property config, i.e.
> <bean id="qa-util-initProfileImpl"
>class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
> <property
>name="staticMethod"><value>com.whatever.qaserver.device.ProfileClassesInit.initProfileClasses</value></property>
> </bean>
>tnow becomes
> <bean id="qa-util-initProfileImpl"
>class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
> <property
>name="targetMethod"><value>initProfileClasses</value></property>
> <property
>name="targetClass"><value>com.whatever.qaserver.device.ProfileClassesInit</value></property>
> </bean>
>
>As well, this also breaks backwards compatibility for anybody using it.
>Perhaps you can add back the
> staticMethod
>property, and on a set, the code inside it would break up the supplied
>string into calls to setTargetMethod and setTargetClass (it would have
>to create the class itself).
>
>This would allow both forms to be used, and keep backwards compatibility...
>
>Regards,
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>
>
>>The Quartz support is already in CVS, and also in use within the werk3AT app it was intended for... feel free to check it out!
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>>Gesendet: Do 19.02.2004 16:54
>>An: spr...@li...
>>Betreff: RE: [Springframework-developer] Quartz support
>>
>>
>>
>>Daniel,
>>
>>As you say, this is most likely caused by the fact that Quartz uses its own threads. WebSphere seems to associate the JNDI context information with container-managed threads; unfortunately, this does not apply to Quartz threads.
>>
>>However, there's a strategy that should work: pre-locate the JNDI objects, and pass the objects to Quartz' job data map. This way, the Quartz job should receive the pre-located objects when running in its own thread, not needing to do a JNDI lookup itself.
>>
>>The Quartz support classes (to be committed within an hour!) provide the following:
>>
>>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to register JobDetails, Calendars and Triggers with it
>>
>>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger that allow for easy bean-style usage; the latter allow for implicit registration of an associated JobDetail
>>
>>- a FactoryBean for a JobDetail that invokes a method of an existing object, to avoid the need for writing one-line Job implementations that just delegate to a business method
>>
>>- a convenience implementation of Quartz' Job interface, applying job data map entries as bean properties
>>
>>A configuration example:
>>
>> <bean id="scheduler" class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
>> <property name="triggers">
>> <list>
>> <ref bean="myTrigger1"/>
>> <ref bean="myTrigger2"/>
>> </list>
>> </property>
>> </bean>
>>
>> <bean id="myJobDetail1" class="org.springframework.scheduling.quartz.JobDetailBean">
>> <property name="jobClass"><value>werk3.example.MyJob</value></property>
>> <property name="jobDataAsMap">
>> <map>
>> <entry key="testBean">
>> <bean class="org.springframework.beans.TestBean">
>> <property name="age"><value>99</value></property>
>> </bean>
>> </entry>
>> </map>
>> </property>
>> </bean>
>>
>> <bean id="myJobDetail2" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
>> <property name="targetObject"><ref bean="exampleService"/></property>
>> <property name="targetMethod"><value>doSomething</value></property>
>> </bean>
>>
>> <bean id="myTrigger1" class="org.springframework.scheduling.quartz.CronTriggerBean">
>> <property name="jobDetail"><ref bean="myJobDetail1"/></property>
>> <property name="cronExpression"><value>0/5 * * * * ?</value></property>
>> </bean>
>>
>> <bean id="myTrigger2" class="org.springframework.scheduling.quartz.SimpleTriggerBean">
>> <property name="jobDetail"><ref bean="myJobDetail2"/></property>
>> <property name="repeatInterval"><value>1000</value></property>
>> </bean>
>>
>>MyJob (as referenced from "myJobDetail1") can be implemented as follows:
>>
>> public static class MyJob extends QuartzJobBean {
>>
>> private TestBean testBean;
>>
>> public void setTestBean(TestBean testBean) {
>> this.testBean = testBean;
>> }
>>
>> protected void executeInternal(JobExecutionContext jobExecutionContext) {
>> System.out.println("Executing job..." + testBean.getAge());
>> }
>> }
>>
>>Note that the "testBean" entry in the job data map is automatically applied as bean property in MyJob.
>>
>>As a side note, I've refactored Colin's MethodInvokingFactoryBean into org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean and MethodInvokingJobDetailFactoryBean as subclasses. They provide exactly the same invocation capabilities.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Daniel Potter
>>Sent: Thursday, February 19, 2004 4:17 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Quartz support
>>
>>
>>Juergen,
>>I have a question regarding these classes and/or your general experience
>>using Quartz with Spring in an J2EE container. We've run into JNDI
>>lookup issues with jobs that attempt to use Spring beans that contain
>>references to JNDI resources (thru a JndiObjectFactoryBean). It appears
>>the Quartz job doesn't know it's running within the container (even
>>though the scheduler is started in the init() method of a servlet), so it's
>>dependencies fail to locate the default JNDI context (and therefore fail
>>to locate their JNDI dependencies). I assume this is because the
>>scheduler is running in its own thread, so it doesn't have any implicit
>>knowledge of the container. To get around this, we've been
>>forced to use a separate Spring config file for the Quartz jobs that
>>overrides the default JNDI settings used by the JndiObjectFactoryBean
>>like this (as if the job had to connect to JNDI remotely):
>>
>> <!-- JNDI connection information -->
>> <bean id="myJndiTemplate"
>>class="org.springframework.jndi.JndiTemplate">
>> <property name="environment">
>> <props>
>> <prop
>>key="java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialContextFactory</prop>
>> <prop
>>key="java.naming.provider.url">iiop://localhost:9091</prop>
>> <prop key="java.naming.security.credentials">user</prop>
>> <prop key="java.naming.security.principal">pw</prop>
>> </props>
>> </property>
>> </bean>
>>
>> <!-- QUEUE CONNECTION FACTORY -->
>> <bean id="jmsQueueConnectionFactory"
>> class="org.springframework.jndi.JndiObjectFactoryBean"
>> lazy-init="true">
>> <property name="inContainer">
>> <value>false</value>
>> </property>
>> <property name="jndiTemplate">
>> <ref local="myJndiTemplate"/>
>> </property>
>> <property name="jndiName">
>> <value>Example/QueueConnectionFactory</value>
>> </property>
>> </bean>
>>
>>This also requires us to load a separate application context for the
>>Quartz jobs that uses these settings, rather than being able to share
>>the application context used by the rest of the application.
>>
>>Have you ever run into this issue? Do your support classes get around
>>this somehow?
>>
>>Regards,
>>Daniel
>>
>>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] wrote:
>>
>>
>>
>>
>>>Everybody,
>>>
>>>I've revived my Quartz support classes for Spring today. They emerged from a job scheduling consulting project I did in autumn 2003. We have concrete needs for this now at werk3AT, thus the revival: It's about quite simple cron-style scheduling of application jobs.
>>>
>>>The basic idea is to set up a Quartz Scheduler via a SchedulerFactoryBean, also allowing to register scheduled jobs there via a <list> of <refs> to ScheduledJobDefinition beans. A ScheduledJobDefinition is just a simple combination of a Quartz JobDetail and a Quartz Trigger.
>>>
>>>ScheduledJobDefinition bean implementations include:
>>>- DefaultScheduledJobDefinition, allowing to use any implementation of Quartz' Job interface with a declaratively configured job data map and cron trigger
>>>- MethodInvokingJobDefinition, allowing to specify a method of a Spring-managed bean to execute as job (completely declarative, without the need for implementing a custom Job object), with a cron trigger.
>>>
>>>Both job definition beans can link in a separate Quartz Trigger instance instead of a cron expression; DefaultScheduledJobDefinition can also link in a separate Quartz JobDetail instance instead of a job class.
>>>
>>>That's all there is: A simple declarative way of using Quartz within Spring. Typically no rescheduling or the like: All schedules are set up on context startup, defined as bean definitions. Of course, you can also fetch the Scheduler instance and perform any custom scheduling, instead of using preconfigured ScheduledJobDefinition beans.
>>>
>>>The typical usage scenario are low-level jobs within an application, like data synchronization or storage cleanup - all predefined jobs that are just customized by an administrator. Fits nicely into Spring's application context model; most jobs will simply delegate to Spring-managed business objects.
>>>
>>>I expect to have this polished by the end of the week, as we need it at werk3AT quite urgently. I'd like to include this already in Spring 1.0 final, as it's just 6 pretty simple classes (yes, I know - feature freeze - never mind ;-). The main question is where to put it: I suggest "org.springframework.scheduling.quartz".
>>>
>>>If there are no general objections, I'll commit it by the end of this week, for review within the next week - still plenty of time before 1.0 final ;-) Looking forward to your feedback!
>>>
>>>Juergen
>>>
>>>
>>>
|
|
From: <jue...@we...> - 2004-02-19 22:32:13
|
As a little bonus, I've also added scheduling support classes for =
java.util.Timer :-) It's as similar as possible in concept to the Quartz =
support. Of course, it's quite limited in terms of scheduling options: =
delays and periods, that's all that Timer is capable of.
=20
A configuration example:
=20
<bean id=3D"timer" =
class=3D"org.springframework.scheduling.timer.TimerFactoryBean">
<property name=3D"scheduledTimerTasks">
<list>
<ref bean=3D"myScheduledTimerTask"/>
</list>
</property>
</bean>
=20
<bean id=3D"myScheduledTimerTask" =
class=3D"org.springframework.scheduling.timer.ScheduledTimerTask">
<property name=3D"timerTask"><ref bean=3D"myTimerTask"/></property>
<property name=3D"delay"><value>1000</value></property>
<property name=3D"period"><value>2000</value></property>
</bean>
=20
<bean id=3D"myTimerTask" =
class=3D"org.springframework.scheduling.timer.MethodInvokingTimerTaskFact=
oryBean">
<property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
<property name=3D"targetMethod"><value>doSomething</value></property>
</bean>
SchedulerTimerTask also supports a "fixedRate" property, deciding on =
Timer's schedule vs scheduleAtFixedRate. There's nothing else: For more =
demanding needs like cron expressions, choose Quartz.
=20
BTW, the whole Timer support just took about two hours of development =
time ;-)
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 19.02.2004 22:09
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support
Good point - I'll re-add "staticMethod" as convenience setter!
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Do 19.02.2004 21:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support
Hey Juergen,
The Quartz stuff looks like good stuff on an initial lookover.
I do have a comment about your refactoring of MethodInvokingFactoryBean.
For the static method call case, your refactoring is arguably cleaner
because the same property is used for specifyng the method name as for
the non-static case, but on the other hand, static methods are probably
one of the most common uses of this class, and you've turned a one
property config into a two property config, i.e.
<bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
<property
name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClassesI=
nit.initProfileClasses</value></property>
</bean>
tnow becomes
<bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
<property
name=3D"targetMethod"><value>initProfileClasses</value></property>
<property
name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesIn=
it</value></property>
</bean>
As well, this also breaks backwards compatibility for anybody using it.
Perhaps you can add back the
staticMethod
property, and on a set, the code inside it would break up the supplied
string into calls to setTargetMethod and setTargetClass (it would have
to create the class itself).
This would allow both forms to be used, and keep backwards =
compatibility...
Regards,
Colin
j=FCrgen h=F6ller [werk3AT] wrote:
>The Quartz support is already in CVS, and also in use within the =
werk3AT app it was intended for... feel free to check it out!
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Do 19.02.2004 16:54
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Quartz support
>
>
>
>Daniel,
>
>As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.
>
>However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
>
>The Quartz support classes (to be committed within an hour!) provide =
the following:
>
>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
>
>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
>
>- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
>
>- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
>
>A configuration example:
>
> <bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
> <property name=3D"triggers">
> <list>
> <ref bean=3D"myTrigger1"/>
> <ref bean=3D"myTrigger2"/>
> </list>
> </property>
> </bean>
>
> <bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
> <property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
> <property name=3D"jobDataAsMap">
> <map>
> <entry key=3D"testBean">
> <bean =
class=3D"org.springframework.beans.TestBean">
> <property =
name=3D"age"><value>99</value></property>
> </bean>
> </entry>
> </map>
> </property>
> </bean>
>
> <bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
> <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
> <property =
name=3D"targetMethod"><value>doSomething</value></property>
> </bean>
>
> <bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
> <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
> <property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
> </bean>
>
> <bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
> <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
> <property =
name=3D"repeatInterval"><value>1000</value></property>
> </bean>
>
>MyJob (as referenced from "myJobDetail1") can be implemented as =
follows:
>
> public static class MyJob extends QuartzJobBean {
>
> private TestBean testBean;
>
> public void setTestBean(TestBean testBean) {
> this.testBean =3D testBean;
> }
>
> protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
> System.out.println("Executing job..." + =
testBean.getAge());
> }
> }
>
>Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
>
>As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Daniel Potter
>Sent: Thursday, February 19, 2004 4:17 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Quartz support
>
>
>Juergen,
>I have a question regarding these classes and/or your general =
experience
>using Quartz with Spring in an J2EE container. We've run into JNDI
>lookup issues with jobs that attempt to use Spring beans that contain
>references to JNDI resources (thru a JndiObjectFactoryBean). It =
appears
>the Quartz job doesn't know it's running within the container (even
>though the scheduler is started in the init() method of a servlet), so =
it's
>dependencies fail to locate the default JNDI context (and therefore =
fail
>to locate their JNDI dependencies). I assume this is because the
>scheduler is running in its own thread, so it doesn't have any implicit
>knowledge of the container. To get around this, we've been
>forced to use a separate Spring config file for the Quartz jobs that
>overrides the default JNDI settings used by the JndiObjectFactoryBean
>like this (as if the job had to connect to JNDI remotely):
>
> <!-- JNDI connection information -->
> <bean id=3D"myJndiTemplate"
>class=3D"org.springframework.jndi.JndiTemplate">
> <property name=3D"environment">
> <props>
> <prop
>key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialC=
ontextFactory</prop>
> <prop
>key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
> <prop key=3D"java.naming.security.credentials">user</prop>
> <prop key=3D"java.naming.security.principal">pw</prop>
> </props>
> </property>
> </bean>
>
> <!-- QUEUE CONNECTION FACTORY -->
> <bean id=3D"jmsQueueConnectionFactory"
> class=3D"org.springframework.jndi.JndiObjectFactoryBean"
> lazy-init=3D"true">
> <property name=3D"inContainer">
> <value>false</value>
> </property>
> <property name=3D"jndiTemplate">
> <ref local=3D"myJndiTemplate"/>
> </property>
> <property name=3D"jndiName">
> <value>Example/QueueConnectionFactory</value>
> </property>
> </bean>
>
>This also requires us to load a separate application context for the
>Quartz jobs that uses these settings, rather than being able to share
>the application context used by the rest of the application.
>
>Have you ever run into this issue? Do your support classes get around
>this somehow?
>
>Regards,
>Daniel
>
>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] =
wrote:
>
>
>>Everybody,
>>
>>I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
>>
>>The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
>>
>>ScheduledJobDefinition bean implementations include:
>>- DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and =
cron trigger
>>- MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
>>
>>Both job definition beans can link in a separate Quartz Trigger =
instance instead of a cron expression; DefaultScheduledJobDefinition can =
also link in a separate Quartz JobDetail instance instead of a job =
class.
>>
>>That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
>>
>>The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
>>
>>I expect to have this polished by the end of the week, as we need it =
at werk3AT quite urgently. I'd like to include this already in Spring =
1.0 final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
>>
>>If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!
>>
>>Juergen
>> =20
>>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-02-23 22:23:45
|
I've added a demo of scheduling to the imagedb sample app today, =
illustrating how to execute a custom job/task respectively invoke an =
existing method in a scheduled fashion with Quartz or Timer. There are =
alternative "schedulingContext-quartz.xml" and =
"schedulingContext-timer.xml" files, to be activated via the =
"contextConfigLocation" entry in "web.xml".
=20
The custom job respectively task implementation takes a variety of =
parameters to generate a list of image names, write it to the log, and =
send it as email. So imagedb also servers as MailSender example now. In =
total, imagedb illustrates a variety of Spring functionality not covered =
in other sample apps: Velocity, LobHandler, Quartz/Timer, and =
MailSender.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 19.02.2004 23:26
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support
As a little bonus, I've also added scheduling support classes for =
java.util.Timer :-) It's as similar as possible in concept to the Quartz =
support. Of course, it's quite limited in terms of scheduling options: =
delays and periods, that's all that Timer is capable of.
A configuration example:
<bean id=3D"timer" =
class=3D"org.springframework.scheduling.timer.TimerFactoryBean">
<property name=3D"scheduledTimerTasks">
<list>
<ref bean=3D"myScheduledTimerTask"/>
</list>
</property>
</bean>
<bean id=3D"myScheduledTimerTask" =
class=3D"org.springframework.scheduling.timer.ScheduledTimerTask">
<property name=3D"timerTask"><ref bean=3D"myTimerTask"/></property>
<property name=3D"delay"><value>1000</value></property>
<property name=3D"period"><value>2000</value></property>
</bean>
<bean id=3D"myTimerTask" =
class=3D"org.springframework.scheduling.timer.MethodInvokingTimerTaskFact=
oryBean">
<property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
<property name=3D"targetMethod"><value>doSomething</value></property>
</bean>
SchedulerTimerTask also supports a "fixedRate" property, deciding on =
Timer's schedule vs scheduleAtFixedRate. There's nothing else: For more =
demanding needs like cron expressions, choose Quartz.
BTW, the whole Timer support just took about two hours of development =
time ;-)
Juergen
________________________________
Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 19.02.2004 22:09
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support
Good point - I'll re-add "staticMethod" as convenience setter!
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Do 19.02.2004 21:54
An: spr...@li...
Betreff: Re: [Springframework-developer] Quartz support
Hey Juergen,
The Quartz stuff looks like good stuff on an initial lookover.
I do have a comment about your refactoring of MethodInvokingFactoryBean.
For the static method call case, your refactoring is arguably cleaner
because the same property is used for specifyng the method name as for
the non-static case, but on the other hand, static methods are probably
one of the most common uses of this class, and you've turned a one
property config into a two property config, i.e.
<bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
<property
name=3D"staticMethod"><value>com.whatever.qaserver.device.ProfileClassesI=
nit.initProfileClasses</value></property>
</bean>
tnow becomes
<bean id=3D"qa-util-initProfileImpl"
class=3D"org.springframework.beans.factory.config.MethodInvokingFactoryBe=
an">
<property
name=3D"targetMethod"><value>initProfileClasses</value></property>
<property
name=3D"targetClass"><value>com.whatever.qaserver.device.ProfileClassesIn=
it</value></property>
</bean>
As well, this also breaks backwards compatibility for anybody using it.
Perhaps you can add back the
staticMethod
property, and on a set, the code inside it would break up the supplied
string into calls to setTargetMethod and setTargetClass (it would have
to create the class itself).
This would allow both forms to be used, and keep backwards =
compatibility...
Regards,
Colin
j=FCrgen h=F6ller [werk3AT] wrote:
>The Quartz support is already in CVS, and also in use within the =
werk3AT app it was intended for... feel free to check it out!
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Do 19.02.2004 16:54
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Quartz support
>
>
>
>Daniel,
>
>As you say, this is most likely caused by the fact that Quartz uses its =
own threads. WebSphere seems to associate the JNDI context information =
with container-managed threads; unfortunately, this does not apply to =
Quartz threads.
>
>However, there's a strategy that should work: pre-locate the JNDI =
objects, and pass the objects to Quartz' job data map. This way, the =
Quartz job should receive the pre-located objects when running in its =
own thread, not needing to do a JNDI lookup itself.
>
>The Quartz support classes (to be committed within an hour!) provide =
the following:
>
>- a SchedulerFactoryBean that sets up a Quartz Scheduler, allowing to =
register JobDetails, Calendars and Triggers with it
>
>- convenience subclasses of JobDetail, CronTrigger and SimpleTrigger =
that allow for easy bean-style usage; the latter allow for implicit =
registration of an associated JobDetail
>
>- a FactoryBean for a JobDetail that invokes a method of an existing =
object, to avoid the need for writing one-line Job implementations that =
just delegate to a business method
>
>- a convenience implementation of Quartz' Job interface, applying job =
data map entries as bean properties
>
>A configuration example:
>
> <bean id=3D"scheduler" =
class=3D"org.springframework.scheduling.quartz.SchedulerFactoryBean">
> <property name=3D"triggers">
> <list>
> <ref bean=3D"myTrigger1"/>
> <ref bean=3D"myTrigger2"/>
> </list>
> </property>
> </bean>
>
> <bean id=3D"myJobDetail1" =
class=3D"org.springframework.scheduling.quartz.JobDetailBean">
> <property =
name=3D"jobClass"><value>werk3.example.MyJob</value></property>
> <property name=3D"jobDataAsMap">
> <map>
> <entry key=3D"testBean">
> <bean =
class=3D"org.springframework.beans.TestBean">
> <property =
name=3D"age"><value>99</value></property>
> </bean>
> </entry>
> </map>
> </property>
> </bean>
>
> <bean id=3D"myJobDetail2" =
class=3D"org.springframework.scheduling.quartz.MethodInvokingJobDetailFac=
toryBean">
> <property name=3D"targetObject"><ref =
bean=3D"exampleService"/></property>
> <property =
name=3D"targetMethod"><value>doSomething</value></property>
> </bean>
>
> <bean id=3D"myTrigger1" =
class=3D"org.springframework.scheduling.quartz.CronTriggerBean">
> <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail1"/></property>
> <property name=3D"cronExpression"><value>0/5 * * * * =
?</value></property>
> </bean>
>
> <bean id=3D"myTrigger2" =
class=3D"org.springframework.scheduling.quartz.SimpleTriggerBean">
> <property name=3D"jobDetail"><ref =
bean=3D"myJobDetail2"/></property>
> <property =
name=3D"repeatInterval"><value>1000</value></property>
> </bean>
>
>MyJob (as referenced from "myJobDetail1") can be implemented as =
follows:
>
> public static class MyJob extends QuartzJobBean {
>
> private TestBean testBean;
>
> public void setTestBean(TestBean testBean) {
> this.testBean =3D testBean;
> }
>
> protected void executeInternal(JobExecutionContext =
jobExecutionContext) {
> System.out.println("Executing job..." + =
testBean.getAge());
> }
> }
>
>Note that the "testBean" entry in the job data map is automatically =
applied as bean property in MyJob.
>
>As a side note, I've refactored Colin's MethodInvokingFactoryBean into =
org.springframework.util.MethodInvoker, with MethodInvokingFactoryBean =
and MethodInvokingJobDetailFactoryBean as subclasses. They provide =
exactly the same invocation capabilities.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Daniel Potter
>Sent: Thursday, February 19, 2004 4:17 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Quartz support
>
>
>Juergen,
>I have a question regarding these classes and/or your general =
experience
>using Quartz with Spring in an J2EE container. We've run into JNDI
>lookup issues with jobs that attempt to use Spring beans that contain
>references to JNDI resources (thru a JndiObjectFactoryBean). It =
appears
>the Quartz job doesn't know it's running within the container (even
>though the scheduler is started in the init() method of a servlet), so =
it's
>dependencies fail to locate the default JNDI context (and therefore =
fail
>to locate their JNDI dependencies). I assume this is because the
>scheduler is running in its own thread, so it doesn't have any implicit
>knowledge of the container. To get around this, we've been
>forced to use a separate Spring config file for the Quartz jobs that
>overrides the default JNDI settings used by the JndiObjectFactoryBean
>like this (as if the job had to connect to JNDI remotely):
>
> <!-- JNDI connection information -->
> <bean id=3D"myJndiTemplate"
>class=3D"org.springframework.jndi.JndiTemplate">
> <property name=3D"environment">
> <props>
> <prop
>key=3D"java.naming.factory.initial">com.ibm.websphere.naming.WsnInitialC=
ontextFactory</prop>
> <prop
>key=3D"java.naming.provider.url">iiop://localhost:9091</prop>
> <prop key=3D"java.naming.security.credentials">user</prop>
> <prop key=3D"java.naming.security.principal">pw</prop>
> </props>
> </property>
> </bean>
>
> <!-- QUEUE CONNECTION FACTORY -->
> <bean id=3D"jmsQueueConnectionFactory"
> class=3D"org.springframework.jndi.JndiObjectFactoryBean"
> lazy-init=3D"true">
> <property name=3D"inContainer">
> <value>false</value>
> </property>
> <property name=3D"jndiTemplate">
> <ref local=3D"myJndiTemplate"/>
> </property>
> <property name=3D"jndiName">
> <value>Example/QueueConnectionFactory</value>
> </property>
> </bean>
>
>This also requires us to load a separate application context for the
>Quartz jobs that uses these settings, rather than being able to share
>the application context used by the rest of the application.
>
>Have you ever run into this issue? Do your support classes get around
>this somehow?
>
>Regards,
>Daniel
>
>On Wed, Feb 18, 2004 at 11:43:14PM +0100, j?rgen h?ller [werk3AT] =
wrote:
>
>
>>Everybody,
>>
>>I've revived my Quartz support classes for Spring today. They emerged =
from a job scheduling consulting project I did in autumn 2003. We have =
concrete needs for this now at werk3AT, thus the revival: It's about =
quite simple cron-style scheduling of application jobs.
>>
>>The basic idea is to set up a Quartz Scheduler via a =
SchedulerFactoryBean, also allowing to register scheduled jobs there via =
a <list> of <refs> to ScheduledJobDefinition beans. A =
ScheduledJobDefinition is just a simple combination of a Quartz =
JobDetail and a Quartz Trigger.
>>
>>ScheduledJobDefinition bean implementations include:
>>- DefaultScheduledJobDefinition, allowing to use any implementation of =
Quartz' Job interface with a declaratively configured job data map and =
cron trigger
>>- MethodInvokingJobDefinition, allowing to specify a method of a =
Spring-managed bean to execute as job (completely declarative, without =
the need for implementing a custom Job object), with a cron trigger.
>>
>>Both job definition beans can link in a separate Quartz Trigger =
instance instead of a cron expression; DefaultScheduledJobDefinition can =
also link in a separate Quartz JobDetail instance instead of a job =
class.
>>
>>That's all there is: A simple declarative way of using Quartz within =
Spring. Typically no rescheduling or the like: All schedules are set up =
on context startup, defined as bean definitions. Of course, you can also =
fetch the Scheduler instance and perform any custom scheduling, instead =
of using preconfigured ScheduledJobDefinition beans.
>>
>>The typical usage scenario are low-level jobs within an application, =
like data synchronization or storage cleanup - all predefined jobs that =
are just customized by an administrator. Fits nicely into Spring's =
application context model; most jobs will simply delegate to =
Spring-managed business objects.
>>
>>I expect to have this polished by the end of the week, as we need it =
at werk3AT quite urgently. I'd like to include this already in Spring =
1.0 final, as it's just 6 pretty simple classes (yes, I know - feature =
freeze - never mind ;-). The main question is where to put it: I suggest =
"org.springframework.scheduling.quartz".
>>
>>If there are no general objections, I'll commit it by the end of this =
week, for review within the next week - still plenty of time before 1.0 =
final ;-) Looking forward to your feedback!
>>
>>Juergen
>>=20
>>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Raymond L. <alp...@ya...> - 2004-02-26 03:19:38
|
Hi, Great to see Quartz support is here now. From the imagedb example in CVS I could see how can I set up scheduled tasks which the parameters may not be dynamic. But what if I I want to set up tasks will have dynamic parameters? Say, an user placed an item for others to bid. As a result a task is being created, and filled with parameters like the user's ID, and item's ID, etc. and a trigger with the task's execution time specified by the user, which are set in code, instead of in applicationContext.xml. Any hint for me to dig deeper? TIA, Raymond __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools |
