FullAjaxExceptionHandler fails to handle an exception between rendering updates #111

Closed
VsevolodGolovanov opened this Issue Mar 10, 2015 · 5 comments

Projects

None yet

2 participants

@VsevolodGolovanov

When using FullAjaxExceptionHandler, some exceptions during Render Response phase result in a malformed XML response, which doesn't contain changes opening tag - only closing one.

To reproduce it's necessary to trigger an exception while update is not started yet, e.g. during component tree rendering visiting. In my case this happened with an iterative component.

View:

<h:form>
    <h:dataTable id="zzz" value="#{bean.data}" />
    <p:commandButton value="Update" update="zzz"  />
</h:form>

Bean:

public List<String> getData() {
    if (FacesContext.getCurrentInstance().isPostback()
            && FacesContext.getCurrentInstance().getCurrentPhaseId() == PhaseId.RENDER_RESPONSE) {
        throw new RuntimeException();
    }
    return null;
}

The problem is that OmniPartialResponseWriter only decides to call wrapped.endDocument(); if it was in the state of updating at the time. It could implement the inChanges tracking like javax.faces.context.PartialResponseWriter does it, or just call wrapped.endDocument(); on reset unconditionally.

@BalusC
Member
BalusC commented Mar 11, 2015

Which JSF impl/version?

Can't reproduce with Mojarra 2.2.10 / MyFaces 2.2.6.

By the way, business logic in getters == wrong.

@VsevolodGolovanov

Initially encountered with Mojarra 2.2.8 and OmniFaces 1.7.
I've made a reproducer: https://drive.google.com/file/d/0B7odbfohhRNTVnpQMm1SUnZNalk/view?usp=sharing
The issue does persist in Mojarra 2.2.10.
During reproducing I've also discovered, that if an exception is thrown during tree visiting before any updates were rendered, then error page rendering results in another kind of malformed XML.

(In the real application it's actually lazy initialization, not so much business logic.)

@VsevolodGolovanov

Sorry, I made the reproducer in such a way that it doesn't start with OF2.0 due to CDI detection. The issue is reproducible with OF1.10.
Also with Mojarra 2.2.10 the "Throw exception during updating on Render Response" test fails for some reason. The same test passes correctly in 2.2.8-2.2.9. The exception suggests that it's a Mojarra issue.

@BalusC
Member
BalusC commented Mar 14, 2015

Reproduced on WildFly 8.2 + Mojarra 2.2.8. Doesn't seem to be a trivial fix at first sight. There are no conditions I could hook on.

@BalusC BalusC closed this in 8feffa8 May 21, 2016
@BalusC
Member
BalusC commented May 21, 2016 edited

While working on #248 I discovered an opportunity to solve this problem. It was quite simple: just flush the JSF response writer. On the contrary to the expectation, it does not flush the underlying writer, but clears its internal state and buffer. This is even explicitly mentioned in API doc http://docs.oracle.com/javaee/7/api/javax/faces/context/ResponseWriter.html#flush--

Your use case now works for me on both Mojarra 2.2.13 and MyFaces 2.2.10.

Fix is available in today's 2.4-SNAPSHOT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment