I'm using Quartz with the JobStoreCMT configuration and several jobs that need to be run. I started out using QuartzTriggerHandle, but couldn't make it work with multiple jobs and the Quartz database configuration. So I implemented the Quartz Job class in my processors and created my own scheduler. I'm sure this is a bad thing, my jobs work, but I've lost any transaction management I had before. So, what I'm doing (don't judge me):

i think you gave up a little to easy on the QuartzTriggerHandle. I use it all the time and store the jobs in the database using JobStoreCMT w/ handles so that the jobs can be paused, resumed cancelled ,,,etc.

if you want help using the seam's components.. i would be happy to help and give examples.. otherwise im guessing the quartz forum is the place for a quartz discussion.

i think you gave up a little to easy on the QuartzTriggerHandle. I use it all the time and store the jobs in the database using JobStoreCMT w/ handles so that the jobs can be paused, resumed cancelled ,,,etc.

if you want help using the seam's components.. i would be happy to help and give examples.. otherwise im guessing the quartz forum is the place for a quartz discussion.

"lower(quartzHandles.cron) like lower(concat(#{quartzHandlesList.quartzHandles.cron},'%'))",

"lower(quartzHandles.handleName) like lower(concat(#{quartzHandlesList.quartzHandles.handleName},'%'))",

"lower(quartzHandles.methodName) like lower(concat(#{quartzHandlesList.quartzHandles.methodName},'%'))",};

private QuartzHandles quartzHandles = new QuartzHandles();

public QuartzHandlesList() {

setEjbql(EJBQL);

setRestrictionExpressionStrings(Arrays.asList(RESTRICTIONS));

setMaxResults(25);

}

public QuartzHandles getQuartzHandles() {

return quartzHandles;

}

@Override

protected String getPersistenceContextName() {

return "quartzEntityManager";

}

}

here is where it started getting shaky. i had a little trouble getting the vailidator to work.. so i moved some of this mess into another bean...just conversation issues.. and i got tired of fighting it.... dont laugh.. it was a cheap shot and it works. lol

now we need the Asynchronous bean... tricky here.. i didnt see it documented anywhere... looks like it is returning null,, but it is actually returning the handle. seam magic happens.i would have like to have seen a little more said about this. but here it is.

@Name("asyncGenericProcessor")

@AutoCreate

public class AsyncGenericProcessor {

@Logger Log log;

// @In

// EntityManager quartzEntityManager;

@Asynchronous

@Transactional

public QuartzTriggerHandle scheduleQue(@Expiration Date when,

@IntervalCron String cron,

@FinalExpiration Date endDate,

QuartzHandles quartzHandles) throws IOException

{

//quartzHandles = quartzEntityManager.merge(quartzHandles); //this will overwrite the original handle after the initial firing of the job.. dont know why they had it in the example. doesnt work well.

i got tired of making individual asyc beans to handle each job. hence the added complexity with generics.. but write once,, use it everywhere..... if someone knows how to do this in Seam3 / JavaEE6 i would appreciate a help hint

hopefully i didnt fat finger anything copying it over.. should get you up and going in no time.

well without showing my ignerance of hibernate validators, i personally have never used them for anything but validating length, allowable characters, and data types. if you have examples by all means share. ill post the other two xhtmls. i had originally attempted to have the validators in a JSF validator class and use the home object as backing for the JSF Edit page. of course that cuased problems because unlike in previous versions of Seam, 2.2.2 you cannot inject straight into a validator class. (my understanding is the functionality appears again in CDI) you have to use Component.getInstance to get the bean in there. if its a home object you of course will find it difficult to get the same instance or even set the ID in the event of an update to an existing object. i dont know what the problem was.. i was under a lot of stress when i wrote that code. ive written 35+ validators like this and never had to include it in a conversation bean like that to get it to work. when i went to get the ID out of the FacesContext i remember nothing went right. So i just abandoned the effort and simplified it by moving it into the same conversation.. and i belive the way the JSF tag was referencing the validator is what was causing it to not actually put the value of Handle in the bean until the form was submitted.. which of course caused a paradox in that it had to be present for the method validator to return all is well. by all means make this better. colaboration is good...

The hibernate validator he provided creates an annotation to handle that validation. This is a much prettier way of handling the validation. Im planning on incorporating it into my production code.. as well.

Yes im using a job store. Handles are stored in the db. The object is stored in the byte array field. The interfacing between my entity and the ones provided by quartz is handled automatically. The triggers are stored in the quartz ds and the quartz handles are stored in the other. In my project I was sharing tables across all projects on that appserver for quartz. Don't get tripped up by the seperation of the data sources. The beauty of using the seam quartz handle is most of the dirt work is handled automatically. Yes this is an example of a non memory jobstore. The app server can go through a power cycle and the jobs will come right back.just try out the code. Its a working example.