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. (You can see the older deprecated location in WebSocketUpgradeFilter source <https://github.com/eclipse/jetty.project/blob/jetty-9.4.8.v20171121/jetty-websocket/websocket-server/src/main/java/org/eclipse/jetty/websocket/server/WebSocketUpgradeFilter.java#L138-L146> )
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. If you want this exposed, open an issue at https://github.com/eclipse/jetty.project/issues asking for it. 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 ... 1. The WebSocketUpgradeFilter is servlet mapped to "/*" 2. The WebSocketUpgradeFilter performs its own PathMappings lookup based on the request pathInfo and prior mapped WebSocket endpoints. 3. 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. 4. The JsrCreator pulls the PathSpec request attribute always. 5. If the PathSpec is UriTemplatePathSpec, then it will grab the path parameters out via Map<String, String> pathMap = pathSpec.getPathParams(requestPath); Joakim Erdfelt / [email protected] On Tue, Feb 6, 2018 at 3:27 AM, Robert Stepanek <[email protected]> wrote: > Since this is my first post: many thanks to all the Jetty developers! > > Now to my question: I'm reusing the PathMappings and UriTemplatePathSpec > classes of the jetty-http pathmap package for URL routing within my > servlets [1]. I don't need a full-blown REST framework, and these classes > cover all my requirements. I've written small glue code that inspects the > pathInfo of the servlet request and uses a PathMappings class to route the > request to the respective handler method within my servlet, passing the > UriTemplatePathSpec variables as arguments. > > I wonder if there is a more canonical way planned to do this? E.g. is > there a plan for Jetty to use the PathMappings/PathSpec classes for > registering handlers or servlets/filter? I don't see any indication of this > on the jetty-10.0.x branch, nor do I see that the Servlet 4.0 specification > has made path specs any smarter. I did however notice that the PathMap > class will be removed in Jetty 10 in favour of PathMappings, so at least it > seems to safe to build on the new PathMappings classes? > > Thanks, > Cheers, > Robert > > [1] https://github.com/eclipse/jetty.project/tree/jetty-9.4. > x/jetty-http/src/main/java/org/eclipse/jetty/http/pathmap > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
