[CXF-9209] UriInfoImpl#getMatchedResourceTemplate support variable Paths

[jungm]

See CXF-9209

TCK run is passing in TomEE with these changes

[reta]

@jungm I believe this is not the correct implementation since it captures the part of the URI which is outside of the JAX-RS scope. The test case from below is confirming that:

Message m = mockMessage("http://localhost:8080/app", "/foo/one/abc");
assertEquals("/app/foo/one/{name:[a-zA-Z][a-zA-Z_0-9]*}", u.getMatchedResourceTemplate());

I believe the /app should not be included in the resource template (it is managed externally, could be set by servlet container / application server / ...), it is reasonable to assume the correct template in this case should be /foo/one/{name:[a-zA-Z][a-zA-Z_0-9]*}.

[rzo1]

Looking at https://jakarta.ee/specifications/restful-ws/4.0/apidocs/jakarta.ws.rs/jakarta/ws/rs/core/uriinfo#getMatchedResourceTemplate() - I think @reta is right. The Javadoc lists an example on what to expect (it doesn't mention the servlet context path).

[jungm]

agree, pushed a change but that is still WIP - don't think reading the ApplicationPath annotation on every getMatchedResourceTemplate invocation is neither smart nor right considering jaxrs.application.address.ignore so no need to really review this yet

[reta]

@jungm I still have the same concern #2983 (comment), I really don't see what has changed (please correct me if I am wrong). JAX-RS has to be aware of the URL parts that are being configured either on JAX-RS Application or JAX-RS resources - this is what its scope is. The server address (which matchedResourceTemplate represents in this case) does include the "external" that are outside of the JAX-RS scope and should not be part of the matcher logic.

My apologies, I was confused the server address with ResourceUtils address, this part seems to be fine, thank you.

[jungm]

@reta it is being set in ResourceUtils to address, which is being constructed by:

        String address = "/";
        if (!ignoreAppPath) {
            ApplicationPath appPath = locateApplicationPath(app.getClass());
            if (appPath != null) {
                address = appPath.value();
            }
        }
        if (!address.startsWith("/")) {
            address = "/" + address;
        }

So ideally, this is just the annotated @ApplicationPath (with normalization and respect for jaxrs.application.address.ignore) plus the paths of the resources being appended in getMatchedResourceTemplate

Though I do admit this might be hacky, maybe theres a better way to do this I didn't find? I don't really know the CXF code, always happy for feedback :)

[reta]

Yeah, I figured this one out a bit later :D Thank you @jungm , I will look into it as well,

[reta]

I think there are two problems (which we could tackle separately):

• the getMatchedResourceTemplate fix (which fails with exception)
• the application path component (which seems to be not taken into account all the time)

For getMatchedResourceTemplate , I think I have a clean fix, @jungm do you mind if I push a change into your pull request? Thank you

[jungm]

@reta of course, edits for maintainers should be allowed so you can just push to this branch (I think)

[reta]

Thanks @jungm pushed a small change to fix the immediate issue, the sub-resources seem to have a gap here, looking into it (thanks a lot for the test cases).

[jungm]

@reta just let this run through the TCK in TomEE again now, these tests look good (ignoring app path prefix):

04-05-2026 09:34:07:[WebValidatorBase] Unable to find the following search string in the server's response: '/app/resource/three/{x:[a-z]}/{x:[a-z]}' at index: 0
[WebValidatorBase] Server's response:
-------------------------------------------
/resource/three/{x:[a-z]}/{x:[a-z]}
-------------------------------------------

04-05-2026 09:34:07:[WebValidatorBase] Unable to find the following search string in the server's response: '/app/resource/one/{name:[a-zA-Z][a-zA-Z_0-9]*}' at index: 0
[WebValidatorBase] Server's response:
-------------------------------------------
/resource/one/{name:[a-zA-Z][a-zA-Z_0-9]*}
-------------------------------------------

However in these there seems to be a whitespace in the @Path annotations that is being lost, probably another issue that is out of scope for now?

04-05-2026 09:34:07:[WebValidatorBase] Unable to find the following search string in the server's response: '/app/resource/two/{Prefix}{p:/?}{id: ((\d+)?)}/abc/{yeah}' at index: 0
[WebValidatorBase] Server's response:
-------------------------------------------
/resource/two/{Prefix}{p:/?}{id:((\d+)?)}/abc/{yeah}
-------------------------------------------

04-05-2026 09:34:07:[WebValidatorBase] Unable to find the following search string in the server's response: '/app/resource/two/{Prefix}{p:/?}{id: ((\d+)?)}/abc{p2:/?}{number: (([A-Za-z0-9]*)?)}' at index: 0
[WebValidatorBase] Server's response:
-------------------------------------------
/resource/two/{Prefix}{p:/?}{id:((\d+)?)}/abc{p2:/?}{number:(([A-Za-z0-9]*)?)}
-------------------------------------------

[reta]

Thanks a lot for checking @jungm

However in these there seems to be a whitespace in the @path annotations that is being lost, probably another issue that is out of scope for now?

So CXF does trim whitespaces upon pattern extraction (seems on purpose), I will into it shortly as well, thank you