Re: [servlet-dev] @Priority for ServletContainerInitializer

[Greg Wilkins <gregw@xxxxxxxxxxx>]

All,

ordering is really a vexed problem in servlets, with already many poorly defined areas resulting from how we handle descriptor fragments and their ordering.   We can't even clearly define filter ordering, let alone Listeners or SCIs.

So I definitely think we need to do more to support precise ordering of lots of components, but I'm not sure that an annotation is really the best way to go:

• We already have some ordering mechanisms, albeit with some problems.  Layering a new ordering mechanism on top without fixing underlying issues is just going to create more corner cases and contradictions.
• Annotations are baked into the class, which is not flexible enough when combining listeners and SCIs that never knew they would be combined.  There is no universal ordering scale that can be baked in.
• Also because there is no universal ordering scale, it can be hard for developers to come up with a linear representation of order that is robust for future inclusions (see David's point about integers).  A universal ordering implies universal knowledge of all components, when often a component deployer will just know the before/after relationships required by a subset of components.

We already have names for filters, servlets, fragments, so I think extending that so we can name listeners and SCI (with their classname being the default name if not specified otherwise), then before/after clauses in descriptors (or annotations if really necessary) can be used to establish an ordering without every component needing to know about every other component.

tl;dr; We need to do something, but I don't thing @Priority is the silver bullet 

cheers

On Tue, 19 May 2020 at 17:16, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

On Tue, May 19, 2020 at 3:21 AM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:

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).

That, or Stuart's suggestion sounds like a good idea.

Two additional things to consider here:

1. Have a platform coordination or maybe sub-spec (like managed beans) that says something about inner-spec ordering of events during startup and shutdown. Something to make what was discussed here a little bit more predictable: http://javaeesquad.blogspot.com/2015/03/getting-notified-when-java-ee.html

2. In Jakarta Security we have IdentityStores which can be called in a given order (set by a priority as well). However, by registering a single class (fully optional), the user is in full control of this order programmatically, meaning they can effectively veto any store, or have them called in any order.

Perhaps this approach can be considered to be adopted universally, or at least in this case here by Servlet.

Kind regards,

Arjan Tijms

 

- Joakim

On Mon, May 18, 2020 at 10:20 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

Just wondering, what about supporting the @Priority annotation on a ServletContainerInitializer class to help ordering the execution order of these?

Thoughts?

Kind regards,

Arjan Tijms

_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To 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

_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To 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

--

Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com