JobSchedulingDataProcessor.processFileAndScheduleJobs(String, Scheduler, boolean) appears to only work correctly when the named file can be located as a resource in the classpath. When it can't, the user gets an unhelpful exception from the underlying XML parser.

I think that either:

1) the documentation for it should be fixed (incidentally, looks like the javadoc for this method was copied without modification from its overloaded sibling -- refers to "xml file in the *default* location"), and the code changed to catch and report this case more meaningfully, or

2) the code should be changed to handle files outside the classpath


To elaborate...

processFileAndScheduleJobs() calls processFile(), which ultimately accesses the file by calling ClassLoader.getResourceAsStream(). I believe this only returns a non-null value when the file is available in the classpath. If it's not, it returns null, and this null InputStream is given to InputSource. No exception is generated at that point. But, since systemId is set to null on the InputSource in this case too, when parsing starts one gets an unhelpful exception from the XML parser (an NPE from Crimson; a MalformedURLException from Xerces).

At least, I think that Quartz should catch the case where getResourceAsStream() returns null and handle it more meaningfully. The documentation should also be updated.

This can be worked around, however, by replacing a call to...

processor.processFileAndScheduleJobs(fileName, scheduler, true);

with...

processor.processFile(fileName, fileName);
processor.scheduleJobs(processor.getScheduledJobs(), scheduler, true);

That is, pass the file name as the "systemId" as well. It is a bit of a hack but it works, since the parser will load the file indicated by the systemId if the InputSource provides no valid InputStream -- it uses "new URL("file://...").openStream()" in the case of Crimson.

It seems possible to incorporate this into Quartz as well, so as to load both from the classpath and, failing that, the file system.