-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Conversation
@yawkat How to fix the type polution check? |
Wouldn't it be easier to just run the FilterRunner twice, once before once after routing? |
The type pollution is caused by this RouteInfo stuff being moved before the conditional filter routes check:
|
Probably not, this change also eliminates multiple invocation of filtering for status routes etc. |
I don't really like how specific the FilterRunner is to the server now |
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 |
c545d68
to
a1d3a65
Compare
@yawkat Please check the latest version |
Can someone enlighten me what the problem is we are trying to solve here? |
Just to align with JaxRs. You can also have a filter that will change the request to hit a different route. |
ok are we adding an API to achieve that without JAX-RS? If so can we document it? |
It is documented. The is a new PreMatching annotation. |
ok but how does one change the route? |
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)) { |
There was a problem hiding this comment.
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
Co-authored-by: Jonas Konrad <jonas.konrad@oracle.com>
@graemerocher The route is resolved after the pre-matching filter so you can simply modify the request |
but the request is not mutable. Does calling |
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")))
} |
@yawkat The limitation of using the continuation was in my intial implementation, after the changes it also works in pre-matching |
There was a problem hiding this 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 :)
|
No description provided.