[cdi-dev] Defining the order of event thru priority

[Emily Jiang]

As for the interceptors/decorators intercepting calls, it is completely 
depending on the implementation of interceptors/decorators. The 
interceptors/decorators might intercept the invocation or might just call 
into the next one.

e.g.
Given that INT1 has priority 10 and INT2 has priority 5, then the 
invocation order:
would be:
If you just logging the method invocation you would have INT2 -> 
INT1->real method

>From end user point of view, it is invoking the INT2 and then INT1

Therefore, I still think it makes more sense to notify the observers with 
the lowest priority first. Interesting to know what others think.


Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Martin Kouba <mkouba at redhat.com>
To:     Emily Jiang/UK/IBM at IBMGB, Antoine Sabot-Durand 
<antoine at sabot-durand.net>
Cc:     CDI Java EE Specification <cdi-dev at lists.jboss.org>
Date:   29/11/2016 09:59
Subject:        Re: [cdi-dev] Defining the order of event thru priority
Sent by:        cdi-dev-bounces at lists.jboss.org



Dne 29.11.2016 v 10:44 Emily Jiang napsal(a):
> I think differently. For Alternatives, the Alternative with the highest
> value is picked, while the others are ignored. There is no so much
> invoked sequentially.
>
> However, for interceptors/decorators/events, they are chained.
> Therefore, I think events should follow the same fashion as
> interceptors/decorators, which is to follow the ascending order.

Well, there is a big difference between interceptors/decorators and 
events - interceptors/decorators do intercept the invocation and may add 
some logic before and after.

Given that INT1 has priority 10 and INT2 has priority 5, then the chain 
would be:

INT1_BEFORE -> INT2_BEFORE -> INT2_AFTER -> INT1_AFTER

So it somehow makes sense that the interceptor with HIGHEST priority is 
the last one which is able to AFFECT the invocation result.

For events the chain is simple:

OBSERVER1 -> OBSERVER2 -> OBSERVER3

>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emijiang at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
>
>
>
>
> From:        Martin Kouba <mkouba at redhat.com>
> To:        Antoine Sabot-Durand <antoine at sabot-durand.net>, CDI Java EE
> Specification <cdi-dev at lists.jboss.org>
> Date:        28/11/2016 12:10
> Subject:        Re: [cdi-dev] Defining the order of event thru priority
> Sent by:        cdi-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
>
>
>
> Dne 28.11.2016 v 11:43 Antoine Sabot-Durand napsal(a):
>> Hi all,
>>
>> In a recent discussion with Martin, I realized that the use of @Priotiy
>> is not consistent in CDI 1.2:
>>
>> - For Interceptor and decorator the lowest value in @Priority is first
>> (def in interceptor spec and 8.2.1)
>> - For Alternatives the Highest value in @Priroty is first (def in 
5.2.2)
>>
>> Since we have these different interpretation of @Priority value in the
>> spec , we may find more consistent to change the definition of event
>> ordering with the @Priority annotation.
>> Right now we have:
>>
>> "Observers with smaller priority values are called first"
>>
>> We may find more intuitive to change it to:
>>
>> "Observers with higher priority values are called first"
>
> I believe this one makes much more sense...
> +1
>
>>
>> It will remove the oxymoron effect of the sentence and align this
>> ordering on @Alternative way of using @Priorty.
>>
>> Wdyt?
>>
>> Antoine
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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.
>>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
_______________________________________________
cdi-dev mailing list
cdi-dev at 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.



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161129/bd8eb633/attachment-0001.html