Early on I advocated that @Priority should not take an int, but a float or double. Unix/Linux uses numbers with decimal points to identify start order. If service A chose 2.2 and service D chose 2.3 and you want to have a service boot in between them you'd just pick 2.25 or something. Decimals being as they are you can keep splitting far out.
With our int based approach if someone picks 100 and someone later comes and takes 101, there's no getting between them.
I would support @Priority for really all listener-type APIs we have across all specs, but I think we should push for a change from int likely to double (the only safe cast from int).
Are you talking about pushing for this change as part of the javax -> jakarta change? I don't really see any way that you can do this without causing problems for backwards compatibility. Another option could be to add an extra field to represent the fractional part, in your 100 to 101 example you could do:
@Priority(value=100, fractional=501)
Which would give you a value of 100.501 .
Although this is maybe not ideal it might make migration easier.
Stuart
How does this work when there are container provided ServletContainerInitializers and even 3rd party ServletContainerInitializers?
How do you ensure a @Priority annotated SCI gets executed before (or after) one of those other SCIs?
- Joakim
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
