The org.eclipse.jetty.http.
pathmap package was originally created to support the JSR356 (javax.websocket) server behaviors for the URI Template requirement.But over time, it was moved out of the org.eclipse.jetty.websocket package space and into org.eclipse.jetty.http to enable similar support in the default Servlet mappings.
Only the ServletPathSpec is supported if you have a WebAppContext and a traditional deployment.
There are no plans to expose this via the existing APIs on WebAppContext and ServletContextHandler for .addServlet() and .addFilter().
The path mappings in ServletHandler are not currently expose for embedded jetty users.
Note: There is some debate internally within Jetty developers that the search/lookup order of the PathMappings matching logic hasn't been rigorously tested enough (its a touchy area of the Servlet spec).
If you suspect any such behavioral concerns in your usage, let us know!
In the JSR356 (javax.websocket) implementation we use the UriTemplatePathSpec like this ...
- The WebSocketUpgradeFilter is servlet mapped to "/*"
- The WebSocketUpgradeFilter performs its own PathMappings lookup based on the request pathInfo and prior mapped WebSocket endpoints.
- The PathSpec that matched is added to the request.setAttribute(PathSpec.class.getName(), pathSpecMatched) so that other deeper request processing can use it, if needed.
- The JsrCreator pulls the PathSpec request attribute always.
- If the PathSpec is UriTemplatePathSpec, then it will grab the path parameters out via Map<String, String> pathMap = pathSpec.getPathParams(requestPath);