Navigating from a managed bean constructor in ADF Faces JSF 1.2

Question

Navigating from a managed bean constructor in ADF Faces JSF 1.2

Can I go to another page / view from a managed bean constructor? I want this redirect if any exception occurs. I tried many ways:

Try-1:

getFacesContext().responseComplete(); getFacesContext().getApplication().getNavigationHandler().handleNavigation(getFacesContext(), null, "gotoPartError"); getFacesContext().renderResponse();

Try-2:

 getServletResponse().sendRedirect("partError.jspx")

Try-3:

 getFacesContext().responseComplete(); getFacesContext().getExternalContext().redirect(getServletRequest().getContextPath() + "/pages/partError.jspx");

Try-4:

 RequestDispatcher dispatcher = getServletRequest().getRequestDispatcher("partError.jspx"); dispatcher.forward(getServletRequest(), getServletResponse());

Try-5:

 FacesContext context = getFacesContext(); UIViewRoot newPage = context.getApplication().getViewHandler().createView(context, "/partError.jspx"); context.setViewRoot(newPage); context.renderResponse();

Try-6:

 ControllerContext.getInstance().getCurrentViewPort().setViewId("partError");

Try-7:

 Exception Handler in adfc-config.xml

Try-8:

 Custom service handler defined in /.adf/META-INF/services/oracle.adf.view.rich.context.Exceptionhandler which extends oracle.adf.view.rich.context.Exceptionhandler

Try-9:

 By extending JSF Life Cycle

None of them worked. For all the cases that I received

 java.lang.IllegalStateException: Cannot forward after response has been committed

Is JSF 1.2 really impossible? Since I use ADF 11.1.1.6.0, which uses JSF 1.2, some of the above "Try" contain ADF Faces paths.

I need it anyway, it could be JSF 1.2 or ADF Faces to go to the error page. The only way to succeed is to use javascript made from the backend to open the error page in the _self window in case of an error, but I don't really like it.

Any pointer in this question will be very helpful.

+4

exception-handling jsf navigation jsf-1.2 oracle-adf

Tapas bose Jul 07 '13 at 5:39

source share

1 answer

Balusc · Accepted Answer · 2013-07-07T17:20:20+0000

It’s easier to solve the problem if you understand the cause of the problem. A good exception mainly talks about the causes of the problem.

Take a closer look:

java.lang.IllegalStateException: cannot be redirected after response has been received

The answer is complete. This is the point of no return. You may not be able to figure out what the answer was perfect (which, in turn, also did not help the exception itself).

By default, an HTTP response is written to a buffer, which is flushed every ~ 2 KB, depending on the server configuration. Resetting the response buffer causes the written bytes to actually be sent from the server to the client. As soon as this happens for the first time, the answer is considered perfect. This is the point of no return. The server cannot take already written bytes back from the client if the server actually needs to change the response after that.

If you have code that could potentially change the answer, you must call it before the answer is executed.

In your particular case, the managed bean seems to be constructed in the middle of the JSF rendering response phase during the generation of the HTML output. Part of the generated HTML output has already been sent to the client (so the response is complete). You, apparently, refer to the bean request area relatively late on the JSF page, or the response buffer is relatively small, or the HTML <head> relatively large, which causes a flash before the <body> starts, etc.

You really need to call the code before the render response phase. In JSF 1.2, you can use <f:view beforePhase> for this.

eg.

 <f:view beforePhase="#{bean.navigate}">

with

 public void navigate(PhaseEvent event) { if (event.getPhaseId() == PhaseId.RENDER_RESPONSE) { // Do here your job which should run right before the RENDER_RESPONSE. } }

Then your Try-1 and Try-3 will work (you can leave these responseComplete() and renderResponse() lines away, they already took care implicitly).

Try-2 and try-4 are bad. You should avoid importing javax.servlet.* In your bean support. Try-5 is awkward. Try-6, try-7 and try-8 are beyond my capabilities. Try-9 is doable, but very awkward.

Navigating from a managed bean constructor in ADF Faces JSF 1.2

Try-1:

Try-2:

Try-3:

Try-4:

Try-5:

Try-6:

Try-7:

Try-8:

Try-9:

More articles: