deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kouba <mko...@redhat.com>
Subject Re: CdiControl in Java EE?
Date Wed, 29 Feb 2012 11:37:58 GMT
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<struberg@yahoo.de>  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?
>>
>>
>
>



Mime
View raw message