Re: [servlet-dev] @Priority for ServletContainerInitializer

[Mark Thomas <markt@xxxxxxxxxx>]

On 10/06/2020 07:43, Greg Wilkins wrote:
> Stuart et al,
> 
> On Wed, 10 Jun 2020 at 03:18, Stuart Douglas <sdouglas@xxxxxxxxxx
> <mailto:sdouglas@xxxxxxxxxx>> wrote:
> 
> 
>     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.
> 
> 
> Very good point.  So to be precise, perhaps our language should be that
> we order SCI's by the order within the
> META-INF/services/jakarta.servlet.ServletContainerInitializer files,
> which themselves are ordered by the fragment order of any fragment
> descriptor in the same jar/module as the services file.  Any services
> file in a jar without fragment is ordered with the "Others" fragment and
> within the "Others", they are ordered alphabetically by the base
> fragment/module/jar name (ie if the jar/module has a fragment name, then
> use that, else use the module name, else use the basename of the jar
> file).     Is that a total ordering of the application SCIs?

I think ordering within others should be undefined. The spec doesn't
currently define an ordering within others and I'm not convinced we
should add one. If ordering matters, it should be explicitly declared.

> I think we all agree that container provided SCIs are ordered before any
> of these, but do we now need to define an ordering among multiple
> container provided SCIs, or is that a container specific mechanism?  I
> tend to the later, because we don't have anything like the fragment
> mechanism to lean on.

I agree, it should be container specific. As should the mechanism to
exclude/disable/skip a container provided SCI.

Mark