Hi Nigel,
I was asking more around the definition of the destinations themselves.
Currently those properties are static and thus do not allow the developer
to decide at runtime which messages get delivered. In the @SessionScoped
scenario it is likely that if a developer needs a listener to be
@SessionScoped then they intend for the messages to be delivered to the
current session user only. They would thus likely appreciate some
customization on their activation config (especially for message selector)
to allow them to specify the selector dynamically through a call back
method to select messages for, say, the current user principal.
It's just a thought triggered by your suggested addition. If the targets
for delivery are now going to be dynamic would it also be feasible to make
the message selector dynamic?
Evans
On 26 Aug 2015 12:34 PM, "Nigel Deakin" <nigel.deakin_at_oracle.com> wrote:
> 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
>
>