XML and trigger persistence

[Andre]

I'm using quartz .net 0.9, and I'm using an xml file to create jobs.
I'm now checking out persistence using ADOJobStore to an embedded
firebird database, and after having received this exception:

"Class for trigger type '' not found."

went on and debugged the code.
So what I found out is that while processing the file (in my case im
processing a stream with a xml document), couldnt find a place where
the triggers were persisted to the database. The processor finds them
and adds them to the job BUT does not persist them at that point. So
when I call the ScheduleJobs, it goes on to try and find the JobDetail
in the database (StdAdoDelegate (method SelectJobDetail) ), which does
not exist (it was not persisted as well), but the processor handles
it by returning null and in the calling code the job is added to the
scheduler. (JobSchedulingDataProcessor (method
ScheduleJob(JobSchedulingBundle job, IScheduler sched, bool
localOverWriteExistingJobs)).
But the same does not happen with the triggers. After adding the job
to the scheduler it goes on to try and find the trigger in the
database, which also does not exist, but in this case the
StdAdoDelegate (method SelectTrigger) does not manage it cleanly. As
the query does not return results, it goes on to compare the
triggerType:

if (triggerType.Equals(TriggerTypeSimple))
{
...

which was not retrieved from the database so it has its default value
of "", untill it reaches the exception throwing:

else
{
throw new Exception("Class for trigger type '" +
triggerType + "' not found.");
}

So my question is, shouldnt this method return a null trigger as the
SelectJobDetail does so that this can be properly handled above in the
calling code?
Am I missing something? SHOULD the trigger already be in the DB ?
Many thanks for any help.

[Andre]

After checking and re-checking, tried to recompile the code and with
the change I made it works.
I'm positive this must be handled in a similar way as the code that's
using this SelectTrigger method is handling the possibility of a null
return, which is not possible because of this bug.

I added this

if(triggerType.Equals(""))
{
return null;
}

right after the read try and just before this code:

if (triggerType.Equals(TriggerTypeSimple))
{

Hope this is helpful to anyone with the same problem, and it seems to
me that it's a bug that should be looked at.
Cheers.

[Marko Lahma]

Hi Andre,

Thanks for insvestigation and report. This is a real bug. The logic in
SelectTrigger is wrong (actually the braces). The check should only be
made if row was found (the trigger type checking code should be inside
earlier block). I've created a JIRA issue (
http://jira.opensymphony.com/browse/QRTZNET-86 ) and it's already
fixed in trunk.

Cheers,

-Marko