Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of mkouba@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <4F4E0E16.2010103@redhat.com>
Date: Wed, 29 Feb 2012 12:37:58 +0100
From: Martin Kouba <mkouba@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: deltaspike-dev@incubator.apache.org
Subject: Re: CdiControl in Java EE?
References: <1330501987.47796.YahooMailNeo@web171511.mail.ir2.yahoo.com>
 <CAF9TksPYQi9_oY7qJJ+xFYAsVX1ZCk9Exb8ozxVeGRLDCYf45Q@mail.gmail.com>
In-Reply-To: 
 <CAF9TksPYQi9_oY7qJJ+xFYAsVX1ZCk9Exb8ozxVeGRLDCYf45Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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?
>>
>>
>
>