servlet icon indicating copy to clipboard operation
servlet copied to clipboard

Clarify Filter Mapping ordering

Open gregw opened this issue 5 years ago • 3 comments

Consider two filters X & Y are defined in web.xml, but with no mappings Then in 3 fragments A, B and C that have:

  • A maps /* to X
  • B maps /* to Y
  • C maps /foo/* to X

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 Y
  • X>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
  • X>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.

gregw avatar May 21 '20 10:05 gregw

Thanks to @janbartel for this example.

gregw avatar May 21 '20 10:05 gregw

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?

gregw avatar May 21 '20 10:05 gregw

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:

  • A maps /* to X and name D to Z
  • B maps /* to Y
  • C maps /foo/* to X

If 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.

gregw avatar May 21 '20 11:05 gregw