|
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
|