Error Handling: 404 page thrown as a result of trying to load missing/incorrect Dataverse results in large stack trace but otherwise functions.

[kcondon]

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)

[cmbz]

Recommendation: Either fix the problem or mask it using the simple approach suggested by Leonid, above.

[pdurbin]

Related:

• encourage Rewrite library to release a non-snapshot of 6.0.0 #9804