Evans,
On 26/08/2015 05:44, Evans Armitage wrote:
> I take it container discovery and validation still happens at startup even for these CDI listeners?
My proposal was that "JMS listener beans" would be completely ordinary CDI managed beans, created in the same way. The
new portable extension would simply extend their postCreate behaviour to create a JMS consumer, and extend their
preDestroy behaviour to close that consumer. I'm not familiar with those specific events, but I'm not proposing anything
to interfere with them working as normal.
> Is there anything that can be added to allow an @SessionScoped listener that only delivers messages for the current
> session? I think that will be a more common reason to use a @SessionScoped jms listener (i.e only deliver when user
> session exists AND only messages intended for the current user).
A JMS listener bean could have any scope, including @SessionScoped. So once it was injected and created by the
application it would listen for messages until the scope ends and the bean was destroyed.
Over on the cdi-dev list people have suggested we provide some way of automatically creating a listener bean whenever a
new scope starts, so that the application wouldn't have to inject it. If that were the case then an instance of the
listener would be automatically created whenever a new SessionScope starts. (I'm still thinking about this).
> Would adding a message selector callback approach be too much work for container developers for too little gain?
>
I don't understand your question. Can you explain it a bit more?
Nigel