@john: +1 @arne: imo there is no need to import something. the required changes are minimal (locally i'm using our BeanProvider for the lookup and delegate to a default factory of quartz if the lookup fails).
regards, gerhard 2014-06-07 9:46 GMT+02:00 Arne Limburg <[email protected]>: > The stuff would need a review anyway. > > > Am 07.06.14 09:42 schrieb "Romain Manni-Bucau" unter > <[email protected]>: > > >Hi > > > >Isn't Instance too slow? But globally +1 > > > > > > > >Romain Manni-Bucau > >Twitter: @rmannibucau > >Blog: http://rmannibucau.wordpress.com/ > >LinkedIn: http://fr.linkedin.com/in/rmannibucau > >Github: https://github.com/rmannibucau > > > > > >2014-06-07 9:31 GMT+02:00 Arne Limburg <[email protected]>: > > > >> Hi all, > >> > >> I did do some work in this area some time ago (see [1]). > >> If you want, I can commit it to trunk. > >> > >> Cheers, > >> Arne > >> > >> [1] > >> > >> > https://github.com/openknowledge/openknowledge-cdi-extensions/tree/master > >>/o > >> penknowledge-cdi-job/src/main/java/de/openknowledge/cdi/job > >> > >> > >> Am 07.06.14 08:33 schrieb "Romain Manni-Bucau" unter > >> <[email protected]>: > >> > >> >+1. Having a cdi job with constructor injections would be nice > >> >Le 7 juin 2014 03:52, "John D. Ament" <[email protected]> a écrit > >>: > >> > > >> >> Hi, > >> >> > >> >> I noticed that in our scheduler module, we let quartz instantiate the > >> >> job, manually inject into it, and use that to do work. If I have a > >> >> job that is ApplicationScoped, this results in multiple instances > >> >> getting created. > >> >> > >> >> I wonder, would it be better if we try getting a contextual instance > >> >> via JobFactory and simply use that? Then let the listener start any > >> >> necessary contexts. > >> >> > >> >> John > >> >> > >> > >> > >
