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?
