Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: Redefine what Priority annotation means across Jakarta EE specifications

Name `ordinal` is used in Java enums, to define the order within the enumeration. The first one has ordinal 0…

So in this case it may be confusing as well, as for me “ordinal” means in numerical order – e.g. lower number comes before higher number.

 

Tomas

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Mark Struberg <struberg@xxxxxxxxxx>
Reply to: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: Tuesday, 9 November 2021 at 20:24
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [External] : Re: [jakartaee-platform-dev] Redefine what Priority annotation means across Jakarta EE specifications

 

First of all, the @Priority annotation was introduced by the CDI team. As is the specific part of the interceptors spec. Both originally have been part of CDI when spec still was called "Web Beans"...

 

I think we should NOT change anything and also NOT introduce any new annotation. It would just confuse people which are used to the current solution.

 

Whiles the name 'Priority' is probably not the best I think the current behaviour in CDI is fine.

 

JAX-RS made use of the annotation only many years later and in retrospect they should probably have asked people from the CDI EG. Their wording and behaviour of the usage in JAX-RS is imo quite confusing. 

For application supplied providers they define:

 

"Application-supplied providers may be annotated with @Priority. If two or more providers are candidates for a certain task, the one with the highest priority is chosen: the highest priority is defined to be the one with the lowest value in this case."



The highest wins, which is the lowest... omg.



BUT for other parts of JAX-RS it is the other way around:

"The order in which filters and interceptors are executed as part of their corresponding chains is controlled by the @Priority annotation defined in [15]....  Execution chains for extension points ContainerResponse and ClientResponse are sorted in descending order; the higher the number the higher the priority."



Yes, that's probably a mess, but it's not the fault of @Priority in the first place ;)





If we do like to use some fixed annotation based ordering then we should stick with @Priority and explicitly define that the highest number wins. Because changing this annotation now would be a huge pain with a low gain. Because functionally there would be no benefit.





But the whole discussion is probably somewhat moot. Because the original reason for not using @Priority in ConfigSources is that this number is totally dynamic and does not come from within the source at all! That's the reason why it is a method returning an int (could probably be float as well). And to make sure that people do not get confused with the ordering (and because it's really something different) I coined the term 'ordinal', simply because it was not yet taken and thus I could exactly define how I liked it. That was 10 years ago and the name did stick [1]. But if there is a better name which has a big benefit over the current version then I'm happy to hear those better ideas!



LieGrue,

strub







Am 09.11.2021 um 16:20 schrieb Nathan Rauh <nathan.rauh@xxxxxxxxxx>:

 

If I understood Emily's writeup correctly, it sounds like usage is mostly consistent across all of Interceptors, JAX-RS, and CDI processing of interceptors, which all prioritize lower numbers first, whereas only CDI Alternatives use the opposite prioritization (high numbers first).  In that case, we could consider a less intrusive approach of standardizing the more prevalent usage pattern for the existing Priority annotation and introducing a new  optional priority attribute to CDI @Alternative (takes precedence over @Priority when both are specified), which would then be the only part of the programming model that we would encourage users to switch.




From:        "BJ Hargrave" <hargrave@xxxxxxxxxx>
To:        jakartaee-platform-dev@xxxxxxxxxxx
Date:        11/09/2021 08:49 AM
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] Redefine what Priority annotation means across Jakarta EE specifications
Sent by:        "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>




I think C makes the most sense. I did comment on the proposed name of the annotation in the doc.
 
Also, solution C must state that if both the old (Priority) and new annotations are present, the old annotation is ignored.
--

BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
hargrave@xxxxxxxxxx
 
 
----- Original message -----
From: "Brian Stansberry" <brian.stansberry@xxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: "JakartaEE Spec Project Leadership discussions" <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Redefine what Priority annotation means across Jakarta EE specifications
Date: Tue, Nov 9, 2021 09:42
 
So, AIUI the Solution C idea of a new annotation would result in Interceptors/CDI/JAX-RS continuing to support @Priority in EE 10 with the EE 8/9 semantics, and then also support the new one?
 
A solution like that that preserves existing behavior sounds good.
 
On Tue, Nov 9, 2021 at 6:09 AM Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
As promised in last week's Jakarta EE platform call, I have created this doc to list the problem with the annotation of @Priority on Jakarta Annotations specification and proposed a few solutions for further conversation. Please take a look at the doc and comment on this thread on which solution do you prefer. Additionally, if you have other solutions, please add it to the doc.
 

--
Thanks
Emily

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


 
 
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev




_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

Back to the top