This was found as part of payara 6 branch testing: #9685 and was the first issue.
The way to reproduce is to go to a non existent dataverse alias: /dataverse/foobar in the browser. In p5 the large stack trace isn't present so maybe a result of err handling in p6.
Since this doesn't appear to affect the user and it fairly narrow, we're spinning it out from the payara 6 branch to work on separately and not block p6.
There is more discussion around this issue but the basics are above. An example statement stack trace:
faces_context_large_stack_trace (1).txt
From a slack discussion:
Oliver Bertuch
I think what happens is this: JSF sends a 404. The servlet picks it up and redirects to /404.xhtml. This is within the JSF realm (/), so JSF kicks in and sees "wait, I'm already done with this request", handing out the exception.
Oliver Bertuch
I suppose this is the problematic line: https://github.com/poikilotherm/dataverse/blob/0133009d5e705af3d9ea05ac12ac9f59fdf[…]5/src/main/java/edu/harvard/iq/dataverse/NavigationWrapper.java
NavigationWrapper.java
context.responseComplete();
Oliver Bertuch
It is called in sendError(), which is triggered by the wrappers around permission and navigation when the error response is built from here: https://github.com/poikilotherm/dataverse/blob/0133009d5e705af3d9ea05ac12ac9f59fdf[…]d26e5/src/main/java/edu/harvard/iq/dataverse/DataversePage.java
DataversePage.java
landreev
It’s the rewrite rule that’s in play in the /dataverse/foobar case that makes the difference. I.e., if you go directly to the dataverse page instead - /dataverse.xhtml?alias=foobar this behavior isn’t triggered. (edited)
landreev
My line of thinking is that this is just a 404 page… Even if it really needs to be fancy-looking, I would still consider replacing it with something completely static. Also support discussing this in its own dedicated issue. (edited)
landreev
(an easy fix/workaround, that requires zero work on the application side, is to handle this rewrite, from /datavrse/x to /dataverse.xhtml?alias=x on the apache level)
This was found as part of payara 6 branch testing: #9685 and was the first issue.
The way to reproduce is to go to a non existent dataverse alias: /dataverse/foobar in the browser. In p5 the large stack trace isn't present so maybe a result of err handling in p6.
Since this doesn't appear to affect the user and it fairly narrow, we're spinning it out from the payara 6 branch to work on separately and not block p6.
There is more discussion around this issue but the basics are above. An example statement stack trace:
faces_context_large_stack_trace (1).txt
From a slack discussion:
Oliver Bertuch
I think what happens is this: JSF sends a 404. The servlet picks it up and redirects to /404.xhtml. This is within the JSF realm (/), so JSF kicks in and sees "wait, I'm already done with this request", handing out the exception.
Oliver Bertuch
I suppose this is the problematic line: https://github.com/poikilotherm/dataverse/blob/0133009d5e705af3d9ea05ac12ac9f59fdf[…]5/src/main/java/edu/harvard/iq/dataverse/NavigationWrapper.java
NavigationWrapper.java
context.responseComplete();
Oliver Bertuch
It is called in sendError(), which is triggered by the wrappers around permission and navigation when the error response is built from here: https://github.com/poikilotherm/dataverse/blob/0133009d5e705af3d9ea05ac12ac9f59fdf[…]d26e5/src/main/java/edu/harvard/iq/dataverse/DataversePage.java
DataversePage.java
landreev
It’s the rewrite rule that’s in play in the /dataverse/foobar case that makes the difference. I.e., if you go directly to the dataverse page instead - /dataverse.xhtml?alias=foobar this behavior isn’t triggered. (edited)
landreev
My line of thinking is that this is just a 404 page… Even if it really needs to be fancy-looking, I would still consider replacing it with something completely static. Also support discussing this in its own dedicated issue. (edited)
landreev
(an easy fix/workaround, that requires zero work on the application side, is to handle this rewrite, from /datavrse/x to /dataverse.xhtml?alias=x on the apache level)