Integration with consumer projects which already imported Quartz

[fabioformosa]

I report the following quote from the issue #41 raised by @rwellman-ats:

my app already has AutoWiringSpringBeanJobFactory, scheduler, jobDetail, etc. in my existing @configuration (as well as existing Quartz jobs). In order to integrate your API/.jars, I had to duplicate some of your SchedulerConfig beans in my @configuration. I'm still a bit new to the Quartz API but I'm thinking most people will have the same situation as me so you probably need to devise a way to "integrate" with existing application context definitions.

[fabioformosa]

Hi @rwellman-ats, in fact, at the moment, Quartz Manager is meant to be imported in projects which didn't import Quartz. Quartz Manager imports Quartz in a transitive way. But I'm really interested to add this new feature you've mentioned: integration with consumer projects which already imported Quartz and their application context definitions.

Please can you elaborate which&where you've duplicated?

[rwellman-ats]

Sure. I took the following approach to integrate - maybe not the best solution but I was in a hurry :)

• Set application property: quartz.enabled=false [see Note A below]
• Still requires other quartz-manager application properties (see in code snippet below)
• Duplicate a lot of config beans (see in code snippet below -also see Note B below)

[Note A] I might suggest renaming this property to 'quartz-manager.enabled' or 'quartz-manager.quartz.enabled', etc. I just think the semi-generic name you currently use might have a lot of potential for name conflict when integrating into existing codebase(s). In summary, I probably suggest renaming all your application properties to begin with 'quartz-manager'.

[Note B] You will also notice that I renamed a couple of the beans to include "QuartzManager". This is because I needed to resolve the differences between your API beans and my existing beans since there are now two beans of the same type and Spring cannot tell them apart during startup. Then I had to tell my existing config to use my existing beans by using the @Qualifier annotation like this:

@Bean
public SimpleTriggerFactoryBean trigger(@Qualifier("jobDetail") JobDetail job) {

# quartz-manager
quartz.enabled=false
quartz-manager.jobClass=org.baeldung.springquartz.basics.scheduler.SampleJobQuartzManager
job.frequency=4000
job.repeatCount=19

    // =========================================================================
       These are required when the quart-manager property 'quartz.enabled' = false.
    // =========================================================================

    @Value("${quartz-manager.jobClass}")
    private String jobClassname;

    @Bean(name = "triggerMonitor")
    public TriggerMonitor createTriggerMonitor(@Qualifier("jobTrigger") Trigger trigger) {
        TriggerMonitor triggerMonitor = new TriggerMonitorImpl();
        triggerMonitor.setTrigger(trigger);
        return triggerMonitor;
    }

    @Bean(name = "jobTrigger")
    public SimpleTriggerFactoryBean sampleJobTrigger(
            @Qualifier("jobDetailQuartzManager") JobDetail jobDetail,
            @Value("${job.frequency}") long frequency, 
            @Value("${job.repeatCount}") int repeatCount) {
        return createTrigger(jobDetail, frequency, repeatCount);
    }

    private static SimpleTriggerFactoryBean createTrigger(JobDetail jobDetail, long pollFrequencyMs, int repeatCount) {
        final SimpleTriggerFactoryBean factoryBean = new SimpleTriggerFactoryBean();
        factoryBean.setJobDetail(jobDetail);
        factoryBean.setStartDelay(3000L);
        factoryBean.setRepeatInterval(pollFrequencyMs);
        factoryBean.setRepeatCount(repeatCount);
        factoryBean
        .setMisfireInstruction(SimpleTrigger.MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT);// in case of misfire, ignore all missed triggers and continue
        return factoryBean;
    }

    @Bean
    @SuppressWarnings("unchecked")
    public JobDetailFactoryBean jobDetailQuartzManager() throws ClassNotFoundException {
        Class<? extends Job> JobClass = (Class<? extends Job>) Class.forName(jobClassname);
        return createJobDetail(JobClass);
    }

    private static JobDetailFactoryBean createJobDetail(Class<? extends Job> jobClass) {
        JobDetailFactoryBean factoryBean = new JobDetailFactoryBean();
        factoryBean.setJobClass(jobClass);
        factoryBean.setDurability(false);
        return factoryBean;
    }

[fabioformosa]

Put it in the roadmap! The possibility to use quartz-manager in a project already imported Quartz.

In the meanwhile, what if you disable the dependency of Quartz in your project and let quartz-manager to import it, enabling quartz.enabled=true ?

[rwellman-ats]

I'm only trying this as an experiment to help with the what-if question. I am suggesting that this NOT be the method you expect people to take to use this project. So before you read my notes below, let me offer my two cents on how I would expect this to work when it's finished:

• First, it's just my opinion but I think MOST people would want to use your user interface project to enhance/support existing code. Therefore, you have to think about how to wire their pre-existing quartz components into your framework. (It may be difficult to automate this... you probably just have to document to tell them how to do it) This would what be offered by your current 'quartz-manager-starter-api' and 'quartz-manager-starter-ui' dependencies (and we haven't even began to talk about using this with more than one job)
• Second, for those wanting to use it as you currently have it, I would offer a different dependency i.e.
  • that imports the quartz framework
  • that creates required spring beans
  • etc.

[rwellman-ats]

So I tried this with mixed success:

• yes, it sort of worked... it even did not force me to the login page (which might help you identify/debug the other issue)
• however, when I "ran the task" via your user interface, it ran the QuartzManagerDemo job instead of the one that I specified in application.properties
• It also did not seem to pick up the job frequency nor the repeatCount from application.properties so maybe it's not using them in this scenario?

# quartz-manager
quartz.enabled=true
quartz-manager.jobClass=org.baeldung.springquartz.basics.scheduler.SampleJobQuartzManager
job.frequency=4000
job.repeatCount=19

[fabioformosa]

I am suggesting that this NOT be the method you expect people to take to use this project

Hey man, that was meant to be a temporary workaround. Nevermind, actually I put your proposal in the roadmap. Thank you very much for sharing feedback!

[fabioformosa]

Hi @rwellman-ats , the new release (v4.0.4) can coexist with an existing instance of quartz, in the host project. For further details, reach out the doc page