Don't attempt to set response buffer size on a committed response

[Pandrex247]

Changes made to fix #5164 and #5262 causes breakages in the Jakarta EE 10 Security TCK (specifically in the "old" bit).

[INFO]      [exec] [javatest.batch] FAILED........com/sun/ts/tests/securityapi/ham/customform/base/Client.java#testCustomFormHAMHasCorrectQualifier
[INFO]      [exec] [javatest.batch] FAILED........com/sun/ts/tests/securityapi/ham/customform/base/Client.java#testCustomFormHAMValidateRequest
[INFO]      [exec] [javatest.batch] FAILED........com/sun/ts/tests/securityapi/ham/customform/base/Client.java#testCustomFormLoginToContinueErrorPage

This is reproducible in Payara 6 and GlassFish 7 when using a Mojarra version higher than 4.0.0 (the first change was introduced in 4.0.1).

I'm not 100% certain if this is just a workaround for a dodgy flow, but it fixes the TCK.

The TCK fails because Mojarra is attempting to redirect from a login page after authentication and is attempting to set the response buffer size on the redirected request (which has been committed), causing the redirection to fail and the TCK to not find the correct content. If you refresh the page it has been authenticated, so that's working, it just specifically fails at the point of redirection because Mojarra appears to be too optimistically trying to set the response buffer size.

[Pandrex247]

I am very open to changing the log level of the "skip" message, it may be better to have it at something like FINE.

[pizzi80]

I've casual exceptions like this on my webapps, thanks

+1 for the Log level FINE

[BalusC]

The existing checks all log WARN and this is OK as it signals something dodgy is going on and therefore makes the developer aware that the flow the developer was using should be fixed/adjusted/improved. E.g. sending redirect instead of forward and calling responseComplete on FacesContext if it is available.