Reputation: 5544
In my preRenderView
invoked method some validations are performed and if it fails a redirect shall happen.
But i am getting an IllegalStateException
Information: Exception when handling error trying to reset the response.
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:524)
at com.sun.faces.context.ExternalContextImpl.redirect(ExternalContextImpl.java:602)
at package.FacesContextUtils.redirect(FacesContextUtils.java:581)
Here is the code:
public void initPreRenderView(final String value) throws DatabaseException
{
if (value == null)
{
FacesContextUtils.addMessageInvalidLinkRedirect(context, url);
return;
}
}
Basically the utility function consists of:
public static void addMessageInvalidLinkRedirect(FacesContext context, String url)
{
context.addMessage(null, new FacesMessage("Invalid link..."));
try
{
context.getExternalContext().redirect(url);
}
catch (final IOException e)
{
// add error message
}
}
Many answers regarding this topic suppose to add a return after the redirection statement, which I did in the preRenderView method.
Edit:
The redirection takes place and everything works as expected. Just want to get rid of this error message.
Upvotes: 0
Views: 4962
Reputation: 5616
I was getting a similar issue. The problem turned out being that another redirect request was being made before I invoked the one I expected. Because one redirect request had already been made it threw an IllegalStateException.
Upvotes: 2
Reputation: 1108577
The problem is not the presence or absence of the return statement. The problem is that the response cannot be reset. Let's look where this is caused:
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:524)
Based on source code this will be thrown when isCommitted()
returns true
. Thus, the response is already committed. A part of the response has already been sent to the client.
There's nothing in your question which indicates that. So, the cause of the problem has to be sought elsewhere than in the information provided so far. On standard JSF this should not happen, so perhaps you've somewhere a servlet filter which is setting/committing some headers?
Upvotes: 3