yes that is exactly what I do. In WAS and also in TomEE ;)

LieGrue,
strub

On Friday, 11 April 2014, 9:42, Lars-Fredrik Smedberg <[email protected]> 
wrote:
 
Hi Mark
>
>
>Just so I understand it correctly.
>
>
>I can @Inject  a @Stateless bean once and call its @Asynchronous annotated 
>method multiple times to create threads that can process work that uses CDI 
>managed beans?
>
>
>Thanks
>Lars-Fredrik
>
>
>
>On Fri, Apr 11, 2014 at 8:52 AM, Mark Struberg <[email protected]> wrote:
>
>Concurrency utils is a completely different spec and IS broken as it does 
>_not_ define it properly. But for @Asynchronous it's perfectly well defined in 
>the spec.
>>
>>I use this as thread starter for BatchEE and I've tested it in 
>>* TomEE
>>* WAS-8.0.0.6
>>* WAS-8.5.5.1
>>* JBossAS-7.0.3.Final
>>* latest WildFly
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>On Friday, 11 April 2014, 7:15, Romain Manni-Bucau <[email protected]> 
>>wrote:
>> 
>>Ok about the spec but propagation doesnt work for sure (it is a kind of issue 
>>for concurrency utilities)
>>>You are right for the config but i just realize i was really not clear 
>>>(throw new TooLateException). If you sont configure the container, you can 
>>>use a semaphore with 20 permits and the container block you to 10. So it is 
>>>important to have a look too and it can be enough avoiding custom 
>>>potentially buggy code.
>>>Le 10 avr. 2014 22:40, "Mark Struberg" <[email protected]> a écrit :
>>>
>>>
>>>>
>>>>> But not propagated in async pool..and not in ejb 3.1
>>>>Of course it is!
>>>>But you wont find this in the EJB spec - you need to look in the EE 
>>>>umbrella spec and the CDI spec ;)
>>>>
>>>>
>>>>> Ps: you can configure async pool or stateless pool
>>>>Yes, some container allow to configure this. But I'm pretty sure there is 
>>>>nothing in the spec which requires it. So I'd rather hack it myself.
>>>>
>>>>LieGrue,
>>>>strub
>>>>
>>>>
>>>>On Thursday, 10 April 2014, 23:18, Romain Manni-Bucau 
>>>><[email protected]> wrote:
>>>>
>>>>Ps: you can configure async pool or stateless pool to limit concurrency 
>>>>depending the container...but a semaphore enforces it portably
>>>>>Le 10 avr. 2014 22:15, "Romain Manni-Bucau" <[email protected]> a 
>>>>>écrit :
>>>>>
>>>>>But not propagated in async pool..and not in ejb 3.1
>>>>>>Le 10 avr. 2014 20:54, "Mark Struberg" <[email protected]> a écrit :
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>Nope, not right.
>>>>>>>The CDI spec mandates that @RequestScoped is active for all EJB calls. 
>>>>>>>And every subsequent invocation as well of course.
>>>>>>>
>>>>>>>LieGrue,
>>>>>>>strub
>>>>>>>
>>>>>>>
>>>>>>>On Thursday, 10 April 2014, 17:52, Romain Manni-Bucau 
>>>>>>><[email protected]> wrote:
>>>>>>>
>>>>>>>actually @Asynch doesn't mandates to start cdi contexts so request
>>>>>>>>scopes can or not be here but transactions are handled if you remove
>>>>>>>>transaction management.
>>>>>>>>Romain Manni-Bucau
>>>>>>>>Twitter: @rmannibucau
>>>>>>>>Blog: http://rmannibucau.wordpress.com/
>>>>>>>>LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>Github: https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>2014-04-10 17:49 GMT+02:00 Mark Struberg <[email protected]>:
>>>>>>>>> Hi Lars-Fredrik!
>>>>>>>>>
>>>>>>>>> This is one of the rare situations where @Asynchronous is good
>>>>>>>>>
>>>>>>>>> @Stateless
>>>>>>>>> @TransactionManagement(TransactionManagementType.BEAN)
>>>>>>>>> public class ThreadExecutorEjb {
>>>>>>>>>
>>>>>>>>>     @Asynchronous
>>>>>>>>>     public void executeTask(Runnable work, Object config) {
>>>>>>>>>         work.run();
>>>>>>>>>     }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The problem with this approach is that WAS is _really_ picky (and far 
>>>>>>>>> from
>>>>>>>>> the spec imo) when it comes to transactions.
>>>>>>>>> You might play a bit with the TransactionManagement and other stuff
>>>>>>>>> probably.
>>>>>>>>>
>>>>>>>>> LieGrue,
>>>>>>>>> strub
>>>>>>>>> On Thursday, 10 April 2014, 16:21, Romain Manni-Bucau
>>>>>>>>> <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>> Hmm deltaspike is a lib you can put in your app but if you really want
>>>>>>>>> to get rid of it you can copy
>>>>>>>>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob;f=deltaspike/cdictrl/impl-owb/src/main/java/org/apache/deltaspike/cdise/owb/OpenWebBeansContextControl.java;h=9e8ba98d46abc3843e8e5b872c882989a98fe16a;hb=HEAD
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2014-04-10 15:52 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>:
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> Thanks for the hint, however I'm not able to use Deltaspike but only 
>>>>>>>>>> the
>>>>>>>>>> OpenWebbeans included with WebSphere 8.5.5.x...
>>>>>>>>>>
>>>>>>>>>> How can I do this with OpenWebbeans only?
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Lars-Fredrik
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 10, 2014 at 3:47 PM, Romain Manni-Bucau
>>>>>>>>>> <[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> with CdiCtrl of deltaspike you can start/stop contexts. Decorate 
>>>>>>>>>>> your
>>>>>>>>>>> executorService to do it and it should be fine:
>>>>>>>>>>> http://openwebbeans.apache.org/testing_cdictrl.html
>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2014-04-10 15:37 GMT+02:00 Lars-Fredrik Smedberg 
>>>>>>>>>>> <[email protected]>:
>>>>>>>>>>> > Hi
>>>>>>>>>>> >
>>>>>>>>>>> > If I within a thread wishes to start asynchronous "jobs" using the
>>>>>>>>>>> > ExecutorService (and Executors.newFixedThreadPool(...)) and wait 
>>>>>>>>>>> > for
>>>>>>>>>>> > the
>>>>>>>>>>> > Future-result within that same thread I run into the following
>>>>>>>>>>> > exception:
>>>>>>>>>>> >
>>>>>>>>>>> > "WebBeans context with scope type annotation @RequestScoped does 
>>>>>>>>>>> > not
>>>>>>>>>>> > exist
>>>>>>>>>>> > within current thread"
>>>>>>>>>>> >
>>>>>>>>>>> > which is understandable since the managed bean passed used in the
>>>>>>>>>>> > Callable
>>>>>>>>>>> > passed to ExecutorService.submit(...) contains injected beans 
>>>>>>>>>>> > iteself
>>>>>>>>>>> > that
>>>>>>>>>>> > are @RequestScoped.
>>>>>>>>>>> >
>>>>>>>>>>> > Is there any way around this? Suggestions on changing the design
>>>>>>>>>>> > perhaps?
>>>>>>>>>>> >
>>>>>>>>>>> > Regards
>>>>>>>>>>> > Lars-Fredrik Smedberg
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > --
>>>>>>>>>>> > Med vänlig hälsning / Best regards
>>>>>>>>>>> >
>>>>>>>>>>> > Lars-Fredrik Smedberg
>>>>>>>>>>> >
>>>>>>>>>>> > STATEMENT OF CONFIDENTIALITY:
>>>>>>>>>>> > The information contained in this electronic message and any
>>>>>>>>>>> > attachments to this message are intended for the exclusive use of 
>>>>>>>>>>> > the
>>>>>>>>>>> > address(es) and may contain confidential or privileged 
>>>>>>>>>>> > information. If
>>>>>>>>>>> > you are not the intended recipient, please notify Lars-Fredrik 
>>>>>>>>>>> > Smedberg
>>>>>>>>>>> > immediately at [email protected], and destroy all copies of this
>>>>>>>>>>> > message and any attachments.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Med vänlig hälsning / Best regards
>>>>>>>>>>
>>>>>>>>>> Lars-Fredrik Smedberg
>>>>>>>>>>
>>>>>>>>>> STATEMENT OF CONFIDENTIALITY:
>>>>>>>>>> The information contained in this electronic message and any
>>>>>>>>>> attachments to this message are intended for the exclusive use of the
>>>>>>>>>> address(es) and may contain confidential or privileged information. 
>>>>>>>>>> If
>>>>>>>>>> you are not the intended recipient, please notify Lars-Fredrik 
>>>>>>>>>> Smedberg
>>>>>>>>>> immediately at [email protected], and destroy all copies of this
>>>>>>>>>> message and any attachments.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>
>
>-- 
>Med vänlig hälsning / Best regards
>
>Lars-Fredrik Smedberg
>
>STATEMENT OF CONFIDENTIALITY:
>The information contained in this electronic message and any
>attachments to this message are intended for the exclusive use of the
>address(es) and may contain confidential or privileged information. If
>you are not the intended recipient, please notify Lars-Fredrik Smedberg
>immediately at [email protected], and destroy all copies of this 
>message and any attachments. 
>
>

Reply via email to