RESTEasy Reactive: NPE due to some exceptions #22408
Comments
|
/cc @geoand, @stuartwdouglas |
|
Do you have sample code that results in this? |
|
Not trivially, no. But I figure that any HTTP POST call to a GET method should do it if you have a response filter that calls |
|
I tried a simple example like you described in your comment but was not able to reproduce the problem |
|
Well, do you agree that the filter's order is wrong, though? The |
|
Now I am confused... Are you saying that which makes sense to me |
|
Well, this is what I have: |
|
Which is wrong, I guess, and the cause for my NPE. |
|
We'll need a reproducer to see why that happens |
|
Man, this is so far deeply linked with OIDC that I'm not sure I can give you an easy one. I'll try. |
|
Thanks! |
|
Well, this is how we build the handler chain: List<ServerRestHandler> abortHandlingChain = new ArrayList<>(3);
if (interceptorDeployment.getGlobalInterceptorHandler() != null) {
abortHandlingChain.add(interceptorDeployment.getGlobalInterceptorHandler());
}
abortHandlingChain.add(new ExceptionHandler());
if (!interceptors.getContainerResponseFilters().getGlobalResourceInterceptors().isEmpty()) {
abortHandlingChain.addAll(interceptorDeployment.getGlobalResponseInterceptorHandlers());
}
abortHandlingChain.add(ResponseHandler.NO_CUSTOMIZER_INSTANCE);
abortHandlingChain.add(new ResponseWriterHandler(dynamicEntityWriter));So we do have the response filters before we set the response from the result. |
|
And the response filters can call |
|
By comparison, the normal handlers are built this way: addResponseHandler(method, handlers);
addHandlers(handlers, clazz, method, info, HandlerChainCustomizer.Phase.AFTER_RESPONSE_CREATED);
responseFilterHandlers = new ArrayList<>(interceptorDeployment.setupResponseFilterHandler());
handlers.addAll(responseFilterHandlers);
handlers.add(responseWriterHandler); |
|
So I assume that normally, response filters go after the response handler. I'll change it and make a PR. |
|
Well, it's more than just that, because if I do this, I'm out of NPE, but I get a 200 OK and the exception is swallowed. |
|
OK, even more than that. Turns out this time it's my mock that's generating this |
|
Found the bug that turns This happens because I have an exception mapper that doesn't map to anything: @ServerExceptionMapper
public Response mapIt(RuntimeException x) {
return null;
}That was left around after a test.
So damn, this is correct. OK, that's one bug less. Now let's see about the others. |
|
So, now, it looks like from the OIDC perspective, it's intercepting the callback call, making the rest client call to GH, which returns a 406 (fine), which triggers a throwing of OK, so now I got to the bottom of this. I'll make a PR for this as soon as I can. |
Definitely :) |
|
Any update on this? |
|
Lemme create a test. |
|
Finally: #23004 |
(cherry picked from commit 8960603)
(cherry picked from commit 8960603)
|
Fixed in #23004 |
Describe the bug
RR is generating a
javax.ws.rs.NotAllowedException: HTTP 405 Method Not Allowedexception, and for some reason I'm getting an exception mapper of typerest.Application$GeneratedExceptionHandlerFor$RuntimeException$OfMethod$mapIt_Subclass@5fa4a2d5, which returns anullResponse, which we then set ascontext.result.Then we move on to the exception handler chain:
And I'm getting the resource response filters which look at the
Response, which isnulland it generates an NPE:Expected behavior
No response
Actual behavior
No response
How to Reproduce?
No response
Output of
uname -aorverNo response
Output of
java -versionNo response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: