Am I just misunderstanding what these methods are supposed to return or do we have a bug.? I worked around it (will look up the code to share tomorrow if I remember). If it’s a bug, I can try to submit a patch.
On Tue, May 7, 2019 at 9:53 PM Andy McCright <[email protected]> wrote: > Hi James, > > Any luck? Worst case, you should be able to construct the path by > reflection (checking the @Path annotations from the resource class/method) > using @Context ResourceInfo's getResourceClass() and getResourceMethod() > methods. > > Hope this helps, > > Andy > > On Sat, May 4, 2019 at 9:22 AM James Carman <[email protected]> > wrote: > > > log.info("matchedUris: {}", uriInfo.getMatchedURIs()); > > > > yields: > > > > matchedUris: [hello/Foo/1, hello] > > > > On Sat, May 4, 2019 at 10:19 AM Andy McCright > > <[email protected]> wrote: > > > > > > Hi James, > > > > > > I’m away from my computer now, so I cannot say for sure, but I think > > > UriInfo.getMatchedURIs() might get you the unresolved URI - assuming > your > > > filter is not annotated with @PreMatch. > > > > > > Can you give that a try? If it doesn’t work I’ll take a closer look on > > > Monday. > > > > > > Thanks, > > > > > > Andy > > > > > > On Sat, May 4, 2019 at 8:41 AM James Carman < > [email protected]> > > > wrote: > > > > > > > I am trying to use a JAX-RS ContainerRequestFilter to add the full > > > > path template to the MDC. I am injecting the UriInfo via a @Context > > > > injection. I have tried doing this: > > > > > > > > uriInfo.getAbsolutePathBuilder().toTemplate() > > > > > > > > But, that appears to already have the parameters resolved. Is there > a > > > > way to get the full string of the request URI template with the > > > > parameter names in it? > > > > > > >
