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?
