For context, see https://java.net/jira/browse/SERVLET_SPEC-79.
The Servlet 3.0 and 3.1 specs require no specific order for ServletContainerInitializers. This is a serious flaw in the spec, because it eliminates the ability to guarantee that certain code runs before any other code (for example, initialization of logging frameworks). In Servlet 2.5 and earlier, you could guarantee a exact ordering of startup code, but you can't do that anymore. To be clear, the spec does not prohibit the container from ordering them in a certain way, it just doesn't specify an order that should be followed.
Tomcat (confirmed), TomEE (confirmed), JBoss (confirmed), WebLogic (apparent), and WebSphere (apparent) order SCIs according to the order of the web-fragments they appear in. That way, either using <order> or <absolute-ordering>, an application can guarantee that a particular SCI will run first. GlassFish executes SCIs in the order they are returned by the ClassLoader.
I believe it would be an improvement for GlassFish and for the community as a whole if GlassFish would order SCIs according to the web-fragment order, just like the five aforementioned containers. Furthermore, since GlassFish currently copies the URL array from the ClassLoader, rips out URLs that would be excluded by the web-fragment order, then creates a NEW ClassLoader just to load SCIs using the ServiceLoader (a very clunky process, to say the least), this change would represent a major improvement to the process GlassFish uses to load SCIs, and could even improve startup performance.
Finally, I intend to lobby hard for this to be the required behavior in the Servlet 3.2 spec. If GlassFish 3 and 4 implemented this behavior, it would make the argument more compelling, and also require no changes in GlassFish 5 once Servlet 3.2 is finalized.
(FYI: I am filing similar enhancement requests for Resin and Jetty.)