Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages

On 26/08/2015 10:51, arjan tijms wrote: > On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau > <rmannibucau(a)gmail.com&gt; wrote: >> Agree for provided scope but JMS + short time scopes will not match well in >> practise so i would worry more about not "default" scopes which can miss >> these events. > > Short lived scopes like @RequestScoped may not be the best match indeed. > > Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped" > thing, e.g. there's the expectation that only the current thread will > access it. If the JMS provider will asynchronously call a method on > the bean instance from another thread, then this breaks this > assumption. That's an interesting point. Is there anything in the CDI spec which would forbid the use of a @RequestScoped JMS listener bean from another thread?

Perhaps all that is needed is to make it clear to users that this is what would happen. The same issue would arise if the user injected a dependent-scoped JMS listener bean into a @RequestScoped bean. It's worth considering threading more generally. Although the JMS provider (resource adapter, actually) can make sure that the callback method won't be called from multiple JMS provider threads at the same time, it can't guarantee that an application thread won't be calling a business method on the bean at the same time. (Would it want to?) Nigel _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.