Quartz in Spring; jobDataAsMap serialization for multiple-use job bean

Question

I have an extension to QuartzJobBean that takes two parameters:

public class FileListProcessorJob extends QuartzJobBean
{
  transient static final Logger logger = Logger.getLogger(FileListProcessorJob.class);
  FileListProcessor fileProcessor;  // with setter
  FileListProcessor fileProcessor2;  // with setter

// ...
}

I have 4 quartz jobs in this application that use this bean; it is the number of times I have that processes a set of files from a folder, then does another set.

It works fine in my test environment, but when I moved it to development, I had to configure Quartz for a database datasource since it was to work in a cluster. When I did that, the runtime started telling me that "fileProcessor" was not serializable. I've tried to make it serializable, but the message is still there.

There are three different bean classes and four different beans loaded under fileProcessor; I've been over all of them to ensure they are serializable, but the message still appears. The message also appears to indicate that the log4j Logger is the non-serializable entity, but I can't see how that is. I made it transient in one pass, no difference.

The standard answers to the serializable problem I find on SO and elsewhere involve moving making a call within the job bean to the job execution context, passing in the reference through SchedulerContextAsMap. But, as near as I can tell, this depends on having globally unique names for the parameters to which to load the globally unique bean names, which doesn't work as I have this set up. I re-use the parameters since I re-use the bean itself.

I'm new to Spring design, but I thought this was the way it was supposed to work -- reusable components, configured with XML to avoid having similar classes slightly modified to do different things. So how can I make my 4 jobs work? Do I have to copy-and-paste them, then slightly modify the names so they're different, and unique in the configuration? Or is there some other piece I am missing and can use here?

Answer 1

There were two levels of problem to be solved; getting something to be serialized takes some painstaking examination and alteration of code, and the clustered environment writes serialized forms of the beans to the database and then uses them in preference to (or in place of, or addition to, I'm not sure) the spring/quartz configuration files. Once I got ALL the serialization necessaries done, and wiped the database records of all the jobs that had been stored there, it worked more like I had expected.