Hi,
On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <nigel.deakin(a)oracle.com> wrote:
In the case of a "JMS listener bean" with @RequestScoped
(or any scope,
really) then the JMS consumer (the thread which receives a message from the
JMS server and invokes the listener) is associated with the actual bean
instance.
Indeed, so the call takes place in the context of the JMS consumer
thread and happens to the "bare" bean instance and does not go through
the proxy that's normally used to access that bean.
However once you're inside the callback method then this request
scope
(which relates to a different thread) is not available.
So this would be an important detail for the user to take into
account. The callback method is NOT allowed to access any other normal
scoped beans, be it via injection, beanmanager lookup or whatever.
E.g. given:
@RequestScoped
public class MyCDIBean21 {
@Inject
private MyRequestScopedBean requestBean;
@JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
)
@JMSConnectionFactory("java:global/MyCF")
@MessageSelector("ticker='ORCL'")
public void processNewsItem(String newsItem) {
...
}
}
Then the callback processNewsItem() can not use requestBean, since
it's a proxy and it will try to delegate to a scope that does not
exist for that thread.
Alternative, if there's an other @RequestScope active (as suggested
below) it will end up calling a different bean instance than the user
may expect.
While it could work, I wonder if this aspect wouldn't be a bit confusing?