3

I guess the title is quite self-explained. I have a job:

import org.apache.deltaspike.scheduler.api.Scheduled;
import org.quartz.Job;

@Scheduled(cronExpression = "0 0/1 * * * ?")
public class JobA implements Job {
  //job code
}

harcoded to run every minute. I would like to set that cron expression from outside, i.e. a config file. I'm using Deltaspike, I can't find a way to achieve it. I was thinking of a class JobDispatcher maybe, from where to create the job and set the cron expression to it, but I see no clue in DeltaSpike documentation

Thanks in advance!

McCoy
  • 780
  • 1
  • 10
  • 21

2 Answers2

1

Make the Cron expression a private final static constant deriving its value from a config file and use it in the annotation.

Rami Del Toro
  • 1,130
  • 9
  • 24
  • Thanks for the answer! the annotation accepts constants as you pointed out, but a constant cannot be changed at runtime (only manipulated in some rough ways), so it's not possible (to my knowledge) to get the value from the file and set it to the constant. – McCoy Mar 25 '15 at 17:28
  • You're welcome. Not sure how you are loading the properties file. The approach I took is load the properties file in an enum (with one instance - singleton) and simply set the static final string. example: private static final String name = PropertiesLoader.INSTANCE.getProperty("NAME"); – Rami Del Toro Mar 25 '15 at 21:17
  • Thanks @Rami ! I used a similar way once, when dealing with Dropwizard. But now, Deltaspike has its own way to load the properties file, Something like this: "@Inject @ConfigProperty(name = "yourProperty") String attHoldingTheValue;", at runtime. Anyway, I'll try what you propose here, maybe using a separate properties file. I'll keep this post updated if I find another way. Thanks a lot! – McCoy Mar 26 '15 at 12:20
1

Well, I ended up using Quartz as it is, through a JobDispatch.java which sets up the scheduler and so, as Quartz specs state, using all libraries from Quartz instead of Deltaspike scheduler module. So far so good, I thought I was totally independent from deltaspike-scheduler-module-api-1.2.1 and deltaspike-scheduler-module-impl-1.2.1, but, the thing is I wasn't. Once everything was working properly, I decided to clean up a little and get rid of those two libraries. I realized then that I had them in my buildpath, so that I removed them from there first, and finally deleted them from disk. For my surprise, when I tried to run my app again, some exceptions came up, NullPointerExceptions in fact, coming from the @Inject variables. I didn't research this deeper, but I let those libs live in the buildpath since it was working right that way.

My thoughts are that in some way, those libs keep the CDI alive through jobs, no matter if all the cronjobs stuff is taken from Quartz libs only.

If anyone can shed some light here, be welcome.

Thanks!

UPDATE 4/2016

Deltaspike 1.6 now supports this kind of functionality: Configurable CRON expressions

UPDATE 2 - 4/2016

For Quartz cron expression, configuration is not so straightforward, check Configuration at container startup time for more information

Community
  • 1
  • 1
McCoy
  • 780
  • 1
  • 10
  • 21