Skip to content

Implement @PreMatching request filter methods #11017

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jul 26, 2024
Merged

Implement @PreMatching request filter methods #11017

merged 8 commits into from
Jul 26, 2024

Conversation

dstepanov
Copy link
Contributor

No description provided.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@dstepanov dstepanov added the type: improvement A minor improvement to an existing feature label Jul 26, 2024
@dstepanov dstepanov requested review from graemerocher and yawkat July 26, 2024 09:01
@dstepanov
Copy link
Contributor Author

@yawkat How to fix the type polution check?

@yawkat
Copy link
Member

yawkat commented Jul 26, 2024

Wouldn't it be easier to just run the FilterRunner twice, once before once after routing?

@yawkat
Copy link
Member

yawkat commented Jul 26, 2024

The type pollution is caused by this RouteInfo stuff being moved before the conditional filter routes check:

return findFilters(request, (RouteMatch<?>) request.getAttribute(HttpAttributes.ROUTE_MATCH)

@dstepanov
Copy link
Contributor Author

Wouldn't it be easier to just run the FilterRunner twice, once before once after routing?

Probably not, this change also eliminates multiple invocation of filtering for status routes etc.

@yawkat
Copy link
Member

yawkat commented Jul 26, 2024

I don't really like how specific the FilterRunner is to the server now

@yawkat
Copy link
Member

yawkat commented Jul 26, 2024

Is it maybe possible to make the routing decision a request filter and insert it between the pre- and post-match filters? I'm not a fan of the api changes to FilterRunner

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@dstepanov dstepanov force-pushed the pref branch 2 times, most recently from c545d68 to a1d3a65 Compare July 26, 2024 11:06
CR

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@dstepanov
Copy link
Contributor Author

@yawkat Please check the latest version

@graemerocher
Copy link
Contributor

Can someone enlighten me what the problem is we are trying to solve here?

@dstepanov
Copy link
Contributor Author

Just to align with JaxRs. You can also have a filter that will change the request to hit a different route.

@graemerocher
Copy link
Contributor

ok are we adding an API to achieve that without JAX-RS? If so can we document it?

@dstepanov
Copy link
Contributor Author

It is documented. The is a new PreMatching annotation.

@graemerocher
Copy link
Contributor

ok but how does one change the route?

@yawkat
Copy link
Member

yawkat commented Jul 26, 2024

I think you'd have to change the request path.

@@ -169,6 +170,9 @@ public void visitMethod(MethodElement element, VisitorContext context) {
}
}
}
if (continuationCreator != null && element.hasStereotype(PreMatching.class)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also check that this is a ServerFilter

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
Co-authored-by: Jonas Konrad <jonas.konrad@oracle.com>
@dstepanov
Copy link
Contributor Author

@graemerocher The route is resolved after the pre-matching filter so you can simply modify the request

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…t-core into pref
@graemerocher
Copy link
Contributor

but the request is not mutable. Does calling mutate() work? It would be good to have a test and example of mutating the route

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@dstepanov
Copy link
Contributor Author

There are ways to mutate it:

        @Order(1)
        @PreMatching
        @RequestFilter
        MutableHttpRequest<?> preMatchingRequest1(MutableHttpRequest<?> request) {
            return request.uri(new URI(request.getUri().toString().replace("xyz", "HELLO")))
        }

        @Order(2)
        @PreMatching
        @RequestFilter
        void preMatchingRequest2(MutableHttpRequest<?> request) {
            request.uri(new URI(request.getUri().toString().replace("HELLO", "abc")))
        }

@dstepanov
Copy link
Contributor Author

@yawkat The limitation of using the continuation was in my intial implementation, after the changes it also works in pre-matching

Copy link
Contributor

@graemerocher graemerocher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, understood. Maybe fix the failing test :)

Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: improvement A minor improvement to an existing feature
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

3 participants