Open gregw opened 4 years ago
Thanks to @janbartel for this example.
See also https://github.com/eclipse-ee4j/jakartaee-schemas/blob/11a456eb82757df7bebcf3dd717c7b5b20d21a96/jakartaee9/src/web-common_5_0.xsds#L420-L423 which suggests that ordering of invocatio is the ordering of the matching, which implies multiple invocations. But note this is contradicted by the spec document in 6.2.4 that says path matches are ordered before servlet name matches.
So a secondary question would be if name matches come after path matches, doe that over rule fragment ordering or is that only ordering within a fragment?
Updating the question for name ordering:
Consider servlet D mapped to /* with three filters X & Y & Z are defined in web.xml, but with no mappings Then in 3 fragments A, B and C that have:
/*
to X and name D
to ZIf a request for /foo/bar
arrives what are the filters invoked:
Y>X>Z
because filter X should only be invoked once and the most specific mapping for X is /foo/* which is defined after the mapping for Y and named mappings come last.
X>Y>Z
because the mapping from fragment C is merged into the mapping created in fragment A, which was defined before the mapping for Y in fragment B and named mappings come last.
X>Z>Y
because the mapping from fragment C is merged into the mapping created in fragment A, which was defined before the mapping for Y in fragment B and named mappings come last only within a fragment.
X>Y>X>Z
because if #52 is resolved to allow multiple mappings to result in multiple invocations, but we preserve the ordering of multiple patterns and named mappings come last.
X>Z>Y>X
because if #52 is resolved to allow multiple mappings to result in multiple invocations, but we preserve the ordering of multiple patterns and named mappings come last only within a fragment.
X>X>Y>Z
because if #52 is resolved to allow multiple mappings to result in multiple invocations, but we merge the multiple patterns into the first defined mapping and named mappings come last..
X>X>Z>Y
because if #52 is resolved to allow multiple mappings to result in multiple invocations, but we merge the multiple patterns into the first defined mapping and named mappings come last only within a fragment.
Consider two filters X & Y are defined in web.xml, but with no mappings Then in 3 fragments A, B and C that have:
If a request for
/foo/bar
arrives what are the filters invoked:Y>X
because filter X should only be invoked once and the most specific mapping for X is /foo/* which is defined after the mapping for YX>Y
because the mapping from fragment C is merged into the mapping created in fragment A, which was defined before the mapping for Y in fragment BX>Y>X
because if #52 is resolved to allow multiple mappings to result in multiple invocations, but we preserve the ordering of multiple patterns.X>X>Y
because if #52 is resolved to allow multiple mappings to result in multiple invocations, but we merge the multiple patterns into the first defined mapping.