Hi Martin! The 'TISS Quartz Extension' is written by my university colleague Ronald Steininger and used in our TISS project [1] and is not public yet. But he and Arne are currently merging this + the OpenKnowledge Quartz Extension over to deltaspike and writing a paper about it.
After discussing this for a while now and checking the code, I think we don't need any @ThreadScoped nor @RequestScoped for the Quartz Extension itself. It is not technically needed for the Extension itself. IF the user likes to run stuff as Quartz jobs which needs @RequestScoped beans then he might just start the context via CdiControl in a portable way. @Gerhard you are right that it isn't especially easy to provide those CdiContainer-impls for ALL EE Containers, but it's by far better than having container specific code directly in the users project! LieGrue, strub [1] https://tiss.tuwien.ac.at ----- Original Message ----- > From: Martin Kouba <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, February 29, 2012 12:37 PM > Subject: Re: CdiControl in Java EE? > > Hi, > > +1 to 2.) as using RequestScoped beans during job execution seems to me > pretty > useful. AFAIK Seam Cron does not support request context during job execution > [1]. > > +1 to "some kind of Context-Control to the CDI-1.1 spec". Right now > similar integration requires CDI impl specific code which is not very > practical. > BTW my own simple Quartz integration experiment is using Weld API to handle > this > [2]. > > Mark: TISS Quartz Extension? Google didn't find anything :-). Is the source > available somewhere? > > [1] > https://issues.jboss.org/browse/SEAMCRON-6 > [2] > https://github.com/symbiont/cdiqi > > Martin > > > Dne 29.2.2012 09:06, Jason Porter napsal(a): >> All sounds good to me. >> >> We could try to get Peter Royal to explain Seam 3 Cron, but I'm not > sure >> what his availability is. >> >> On Wed, Feb 29, 2012 at 00:53, Mark Struberg<[email protected]> > wrote: >> >>> Hi! >>> >>> Pete did ask me a few days ago if the CdiContainer is really only > targeted >>> to JavaSE. >>> Well, basically it _was_. But yesterday I reviewed the 3 Quartz > Extensions >>> from Ronald, OpenKnowledge and Seam3 and when looking at the first 2 I > saw >>> that >>> >>> 1.) OpenKnowledge introduces an own Context named @ThreadScoped and > start >>> it manually in the newly started Quartz thread. >>> >>> 2.) our TISS Quartz Extension (done by Ronald) uses OWB specific code > to >>> start a RequestScope for the newly started thread in which Quartz runs. >>> >>> I've not looked into the Seam3 extension in detail because it does > a hell >>> lot more and I'm not sure if we really need all that. A few things > look >>> really good but I didn't have enough time to plug them apart. >>> >>> What are the pros and cons of 1.) and 2.) so far? >>> 1.) is CDI container independent but you must not use @RequestScoped >>> because this Context is not active in the new thread. You can use the > new >>> @ThreadScoped but if you use the same @Transactional services for the >>> Quartz job and the rest of your app, then you must not use a > @RequestScoped >>> EntityManager. >>> >>> >>> 2.) Sharing the services between the Quartz job and the rest of the app > is >>> perfectly fine but it's currently Container specific how the > @RequestScoped >>> can get activated for a freshly created thread. >>> >>> >>> And then Pete's words jumped into my head. >>> >>> >>> So, what about using the > CdiContainer#startContext(RequestScoped.class); >>> in that CDI Extension? >>> That looks pretty much perfect to me! >>> >>> We could also provide multiple impls, e.g for: WeldSE, WeldEE, OwbSE, >>> OwbEE, ResinEE, >>> >>> Anyone could easily implement the control part himself if the standard >>> container integration doesn't work out of the box for a certain EE >>> container. >>> If e.g. OwbEE will not work on WebSphere-8.0.2, then its easy to just >>> write an own! >>> >>> >>> >>> wdyt? >>> >>> LieGrue, >>> strub >>> >>> >>> PS: Pete we might add some kind of Context-Control to the CDI-1.1 spec, >>> wdyt? >>> >>> >> >> >
