Filters is a particularly hard problem. Listeners and SCIs are -
hopefully - easier.
For SCIs can't we say:
1) Container provided SCIs are loaded first.
2) SCIs are then loaded as per the order of the fragments with which
they are associated.
Something to be careful here is that I think we need to define 'associated with' as the jar the contains the META-INF/services file, which
can in theory be different to the jar that actually contains the class file.
Stuart
3) SCIs from the same fragment are loaded in the order they are listed
in META-INF/services/jakarta.servlet.ServletContainerInitializer
?
You could argue 2) is implied by 8.2.2.d with 1) and 3) natural
extensions of 2).
Container provided SCIs are loaded first as applications may be
depending on a service provided by the container (we see this in Tomcat
with WebSocket)
Ordering of container provided SCIs is via container specific configuration.
The one scenario this doesn't cover is if JAR A has service A1 and A2
and JAR B has service B1 and the desired order is A1, B1, A2. One
possible solution is say, in that instance, that JAR A needs to be split
into 2 JARs.
Mark
On 09/06/2020 09:03, Greg Wilkins wrote:
> 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
> <https://github.com/eclipse-ee4j/servlet-api/issues/318>, 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
> <mailto:arjan.tijms@xxxxxxxxx>> wrote:
>
> Hi,
>
> On Tue, May 19, 2020 at 3:21 AM David Blevins
> <dblevins@xxxxxxxxxxxxx <mailto: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 <mailto: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 <mailto:servlet-dev@xxxxxxxxxxx>
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/servlet-dev
>>
>> _______________________________________________
>> servlet-dev mailing list
>> servlet-dev@xxxxxxxxxxx <mailto:servlet-dev@xxxxxxxxxxx>
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/servlet-dev
>
> _______________________________________________
> servlet-dev mailing list
> servlet-dev@xxxxxxxxxxx <mailto:servlet-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/servlet-dev
>
> _______________________________________________
> servlet-dev mailing list
> servlet-dev@xxxxxxxxxxx <mailto:servlet-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/servlet-dev
>
>
>
> --
> Greg Wilkins <gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx>> CTO
> http://webtide.com
>
> _______________________________________________
> 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
