Indeed it works, also for me. I have created DELTASPIKE-1032 <https://issues.apache.org/jira/browse/DELTASPIKE-1032> in Jira with an extension to the Scheduler Documentation attached where I describe this particular case of creating and configuring scheduling jobs at runtime. Feel free to take it.
Thanks On Thu, Nov 19, 2015 at 12:56 PM, Gerhard Petracek < [email protected]> wrote: > hi pablo, > > i just tried to reproduce it with the steps you described. > at runtime CdiAwareJobFactory#newJob was called as expected and the > dynamically registered quartz-job was valid > (including the injection-points - tested by injecting > org.apache.deltaspike.core.api.projectstage.ProjectStage). > > regards, > gerhard > > > > 2015-11-19 10:51 GMT+01:00 Pablo Pita <[email protected]>: > > > Hi Gerhard, > > > > I like to check a little bit more the issue. > > > > When unwrapping, we get the Quartz Scheduler instance. At the same time, > we > > have the Quartz JobFactory from DeltaSpike which can create Job instances > > with CDI dependencies fulfilled. This is the mixed situation which I am > not > > succeeding to work with at runtime. > > > > When I create a SQLPollingService using Quartz Scheduler, i do not see > the > > way the JobFactory is involved. In fact, I am using this code: > > .... > > JobKey jobKey = new JobKey(key); > > JobDetail detail = > > JobBuilder.newJob(SQLPollingService.class).withIdentity(jobKey).build(); > > scheduler.scheduleJob(detail, buildPollingTrigger(key)); > > .... > > > > There, CDI does not work. I have this work around in my SQLPollingService > > class: > > > > public class SQLPollingService implements Job { > > @Inject > > DbPolling dbPolling; > > > > @Override > > public void execute(JobExecutionContext context) throws > > JobExecutionException { > > // FIXME: CDI injection should work > > if (dbPolling == null) { > > DependentProvider<DbPolling> beanProvider = > > BeanProvider.getDependent(DbPolling.class); > > dbPolling = beanProvider.get(); > > } > > String table = > > context.getJobDetail().getJobDataMap().getString("table"); > > dbPolling.execute(table); > > } > > > > } > > > > Is there anything that should be done differently on my side? Any > > recommendation? With that basis, I am happy to open the Jira issue. > > > > > > On Wed, Nov 18, 2015 at 5:27 PM, Gerhard Petracek <[email protected]> > > wrote: > > > > > hi pablo, > > > > > > we keep org.apache.deltaspike.scheduler.spi.Scheduler as minimal as > > > possible. > > > with #unwrap it's possible to support special cases, however, please > > create > > > a jira ticket for the suggested improvement. > > > > > > thx & regards, > > > gerhard > > > > > > > > > > > > 2015-11-18 15:30 GMT+01:00 Pablo Pita <[email protected]>: > > > > > > > Hello List, > > > > > > > > > > > > I am trying to implement some functionality this time using the > > > DeltaSpike > > > > Scheduler. Normally, it is quite straightforward, but this time, I am > > > > facing trouble. > > > > > > > > > > > > I have to run some jobs periodically related to polling tables in a > > > > database. To implement this, I use the Scheduler module. After > reading > > > its > > > > documentation, I find easy to schedule jobs that are fully defined at > > > > compile time. But for some cases I like to poll some other tables and > > > make > > > > the polling intervals specific to the table. Therefore, I like to > get a > > > job > > > > instance with its dependencies injected via CDI, then prepare a > Trigger > > > or > > > > something similar, prepare some parameters, and schedule this job. Do > > > > similarly for the other tables by getting a new instance of the same > > > class. > > > > I think this is possible to achieve and I would like to request if > this > > > > case could be treated in the documentation as well. Also any feedback > > on > > > > how to do this, it is welcome. > > > > > > > > > > > > Thanks, > > > > -- > > > > Pablo Pita Leira > > > > > > > > > > > > > > > -- > > Pablo Pita Leira > > > -- Pablo Pita Leira
