hi mark, i never suggested to have container specific code in an application.
regards, gerhard 2012/2/29 Mark Struberg <[email protected]> > 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? > >>> > >>> > >> > >> > > >
