Since the specification allows the application configuration resources to be
composed of multiple configuration files (web.xml and web-fragment.xml),
discovered and loaded from several different places in the application, the question
of ordering must be addressed.
The web.xml (or web-fragment.xml) must have a <name> element to participate in ordering.
Since you are dealing with web.xml, you will need to use the absolute ordering:
1. Absolute ordering: an <absolute-ordering> element in the web.xml.
a. In this case, ordering preferences that would have been handled by case 2
below must be ignored.
b. The web.xml MUST be processed before any of the web-fragments listed in the
c. Any <name> element direct children of the <absolute-ordering> MUST be
interpreted as indicating the absolute ordering in which those named web-
fragments, which may or may not be present, must be processed.
d. The <absolute-ordering> element may contain zero or one <others />
element. The required action for this element is described below. If the
<absolute-ordering> element does not contain an <others/> element,
any web-fragment not specifically mentioned within <name /> elements
MUST be ignored. Excluded jars are not scanned for annotated servlets, filters
or listeners. However, if a servlet, filter or listener from an excluded jar is listed
in web.xml or a non-excluded web-fragment.xml, then it's annotations will
apply unless otherwise excluded by metadata-complete.
ServletContextListeners discovered in TLD files of excluded jars are not
able to configure filters and servlets using the programmatic APIs. Any
attempt to do so will result in an IllegalStateException. If a discovered
ServletContainerInitializer is loaded from an excluded jar, it will be
ignored. Excluded jars are not scanned for classes to be handled by any
e. Duplicate name exception: if, when traversing the children of <absolute-
ordering>, multiple children with the same <name> element are encountered,
only the first such occurrence must be considered.