Chapter 13. Quartz and Web Applications

Up to this point, our interaction with the Quartz framework has primarily been through the command line. For users such as my old college computer science professor (who would tell me every day, "GUIs are for wimps!"), command-line usage is very acceptable. When applications are developed and finished, however, they are often turned over to end users or support teams . Putting GUI front ends on top of command-line applications can be quite helpful and much appreciated. This chapter describes how to use Quartz within Web applications to make scheduling and maintaining jobs easier.

Using Quartz Within a Web Application

By now, you've seen many examples of Quartz running as a stand-alone application in a J2SE environment. In Chapter 10, "Using Quartz with J2EE," you also learned that Quartz can function well running within a J2EE environment. But what we haven't shown you is how to deploy Quartz within a Java Web application (normally abbreviated as Web app). That is the sole intent of this chapter.

You might want to integrate Quartz within a Web application for several reasons. A few of the more obvious ones are listed here:

To schedule and launch jobs using a GUI interface
To improve job management and monitoring
To make it easier for multiple users to schedule jobs
To schedule jobs from within your own Web applications

The primary use of Quartz within a Web app is, of course, to allow easier scheduling and maintenance of jobs through a GUI interface. Other secondary reasons include better management of running and scheduled jobs, as well as quicker notification when things go wrong. In general, the same reasons that you would want to put a GUI around any software application can be generalized for applications using Quartz: to make it easier to use the application.

Integrating Quartz

Fortunately, two things make it easy to integrate Quartz into a Web application. First, the list of third-party libraries the Quartz framework requires is pretty straightforward. Most of the third-party dependencies already are included in any Java Web application, especially ones built with open source frameworks such as Apache Struts. When deploying Quartz within a Web application, Quartz requires the following third-party libraries:

Commons BeanUtils
Commons Collections
Commons Logging
Commons Digester

If you've built Java Web applications before, you've seen all these listed here. A few other JARs might be necessary, depending on your exact deployment of Quartz. For example, if Quartz stores its job information in a database, the Standard JDBC APIs library ( jdbc2_0-stdext.jar ) is required, along with possibly the Java Transaction API ( jta.jar ).

You might also need some optional libraries, depending on the totality of your requirements. For example, if your application needs to send e- mails , you'll need the activation and JavaMail libraries. But this is true whether you are deploying Quartz within a Web application or just as a stand-alone application.

Structure of a Web Application

Over the past several years , the Servlet and JSP specifications have improved and allowed for better portability between tool vendors . This has had a calming effect on the Java development community and allows Web developers to focus on the "real" business needs and not on what has to be done to get the application to deploy and run.

Installing the Quartz Libraries

As in any other Java Web application, the Servlet specification instructs that all JARs (third-party or otherwise ) must be placed into WEB-INF/lib . Therefore, one of the first steps is to put the quartz.jar file and its dependent JARs into the WEB-INF/lib directory.

JAR Version and Location Do Matter

You must be careful about not only which JAR files you put in a Web application, but also which version of the JAR you are using and exactly where you put it. As the development community continues to mature, more continuous integration is occurring across independent projects. So issues such as one project depending on an out-of-date version of another project are becoming less frequent. Be sure to check the dependencies before upgrading to newer versions of libraries.

The other thing to keep in mind is that it's extremely important (and sometimes confusing) where you install libraries. Fortunately, Web container vendors are starting to adhere to specifications more closely, and developers are becoming more educated . For Web applications, you almost always want to install any third-party library (specific to your application) into the WEB-INF/lib directory. Issues with XML parsers and encryption packages such as Sun Java Secure Socket Extensions (JSSE) still pop up, but these are becoming rare as commercial and open source vendors update their releases.

Choosing a Web Application Framework

It's entirely up to you which Java Web application framework you choose to integrate with Quartz. So many frameworks are available that it can be quite overwhelming. To say that one particular framework is better than another is very subjective because a lot has to do with your requirements and skill set. However, a few Web frameworks have proven themselves over time. One example is the Apache Struts framework (formerly known as Jakarta Struts). For the purpose of this section, we will use the Struts framework to demonstrate how to integrate with Quartz.