Hi Nigel,
I like proposed suggestion.
Regards,
Vaquar khan
On 26 Aug 2015 17:07, "Evans Armitage" <evans.armitage_at_gmail.com> wrote:
> 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
>>
>>