I use the SchedulerFactoryBean to manager the Quartz Scheduler lifecycle.

spring-servlet.xml

...
	<!-- Quartz -->
	<bean id="scheduler" class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
		<property name="applicationContextSchedulerContextKey" value="applicationContext"/>
		<property name="configLocation" value="classpath:quartz.properties"/>
	</bean>
...

The Quartz settings are stored in a quartz.properties file so that they can be unique to each instance of the web application. This setup requires that quartz.properties be on the classpath. This file defines the JDBC connection for Quartz to use.

quartz.properties

...
org.quartz.dataSource.myDS.jndiURL=java:comp/env/jdbc/MyDS
org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.dataSource=myDS
org.quartz.jobStore.tablePrefix=JB_
org.quartz.jobStore.useProperties=true

MyBaseJob

public abstract class MyBaseJob extends QuartzJobBean
{
    private transient ApplicationContext applicationContext = null;

    public ApplicationContext getApplicationContext()
    {
        return applicationContext;
    }

    public void setApplicationContext(ApplicationContext applicationContext)
    {
        this.applicationContext = applicationContext;
    }
}

Each of my job classes extend MyBaseJob, overriding executeInternal. The jobs can use the applicationContext to lookup Spring service beans. In my environment these service beans extend HibernateDaoSupport.

    protected void executeInternal(JobExecutionContext ctx) throws JobExecutionException
    {
        MyServiceManager sm = applicationContext.getBean("myServiceManager"); // lookup Spring service bean
        ...
    }

org.apache.commons.digester.Digester startElement
SEVERE: Begin event threw exception
java.lang.ClassNotFoundException: com.mikwat.struts.config.AuthorizationActionConfig

The root of the problems appears to be that the Digester defaults to using the same ClassLoader that loaded it and whichever ClassLoader this is, it doesn’t have access to my webapp class com.mikwat.struts.config.AuthorizationActionConfig.

After Googling around, I eventually came across this post regarding a similar problem loading the Quartz plugin: Mailing list archives.

The solution is to call setUseContextClassLoader(true) on the Digester object which forces it to use the ClassLoader found by calling Thread.currentThread().getContextClassLoader().

Solution Under Linux: This problem is avoided by starting the application with a working directory of <application.root>\temp Then, these ADF cache files get dumped there. The following snip-it does the trick:

pushd "$CATALINA_BASE"/temp > /dev/null
exec "$EXECUTABLE" start "$@"
popd > /dev/null


CATALINA_BASE: <application.root>

EXECUTABLE: <tomcat.home>/bin/catalina.sh

Solution Under Windows: Unknown at this point, please provide feedback.

java -classpath
".;X:Javaaxis-1_3libaxis.jar;X:Javaaxis-1_3libcommons-logging-1.0.4.jar;X:Javaaxis-1_3libcommons-discovery-0.2.jar;X:Javaaxis-1_3libjaxrpc.jar;X:javaaxis-1_3libsaaj.jar;X:javaaxis-1_3libwsdl4j-1.5.1.jar"
org.apache.axis.wsdl.WSDL2Java service.wsdl

Error while processing message: java.lang.NumberFormatException: For input string: ""

After digging through HAPI source, it was found that the <hapi.home>/id_file has to be removed. Here is an excerpt of the helpful code comment:

/**
 * Creates unique message IDs.  IDs are stored in a file called <hapi.home>/id_file for persistence
 * across JVM sessions.  Note that if one day you run the JVM with a new working directory,
 * you must move or copy id_file into this directory so that new ID numbers will begin
 * with the last one used, rather than starting over again.
 * @author Neal Acharya
 */