Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: EE-1.8.2.GA_P03
-
Fix Version/s: 1.8.3, EE-1.8.2.GA_P04
-
Component/s: Framework
-
Labels:None
-
Environment:Seam 2.2, Weblogic 10.3.5, just-ice.jar + RunnableRenderer run() fix
Description
The following exception is thrown when attempting a push to a non existent view after session expiry. This exception has no functional impact but does clutter the log files. Full exception attached to the case.
[ERROR] 04:34 (PersistentFacesState.java:execute:295)
Exception occured during execute push on Unknown View
javax.faces.FacesException: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:128)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:102)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.execute(PersistentFacesState.java:286)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:312)
....................
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:175)
at org.jboss.seam.jsf.SeamStateManager.restoreView(SeamStateManager.java:76)
at com.icesoft.faces.application.D2DViewHandler.restoreView(D2DViewHandler.java:258)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:179)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
There are two ways to reproduce the issue in the sample:
1. Bounce the server, reload the page via the NIC popup, and click the link to request a session render.
2. Wait for the session to expire, reload, and again click the link to call the SessionRenderer.
The just-ice.jar being used (SVN details below), has a fix that does reduce the frequency of the exception, which previously was being thrown after each requestRender call. The added fix was to add an extra catch block to the run() in RunnableRenderer like so:
} catch (FacesException e) {
renderable.renderingException(new TransientRenderingException(e));
}
[ERROR] 04:34 (PersistentFacesState.java:execute:295)
Exception occured during execute push on Unknown View
javax.faces.FacesException: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:128)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:102)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.execute(PersistentFacesState.java:286)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:312)
....................
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:175)
at org.jboss.seam.jsf.SeamStateManager.restoreView(SeamStateManager.java:76)
at com.icesoft.faces.application.D2DViewHandler.restoreView(D2DViewHandler.java:258)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:179)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
There are two ways to reproduce the issue in the sample:
1. Bounce the server, reload the page via the NIC popup, and click the link to request a session render.
2. Wait for the session to expire, reload, and again click the link to call the SessionRenderer.
The just-ice.jar being used (SVN details below), has a fix that does reduce the frequency of the exception, which previously was being thrown after each requestRender call. The added fix was to add an extra catch block to the run() in RunnableRenderer like so:
} catch (FacesException e) {
renderable.renderingException(new TransientRenderingException(e));
}
Activity
| Status | Reopened [ 4 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | EE-1.8.2.GA_P04 [ 10280 ] | |
| Affects Version/s | EE-1.8.2.GA_P03 [ 10251 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 1.8.3 [ 10211 ] |
| Assignee | Ted Goddard [ ted.goddard ] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #28521 | Mon Mar 26 10:15:29 MDT 2012 | ted.goddard | dispose views that cannot be identified during push ( |
| Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java
|
The following change results in just one Exception being logged, not a series:
+++ src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java (working copy)
@@ -177,7 +177,9 @@
String viewID = "Unknown View";
try
+ } catch (NullPointerException npe) { + view.dispose(); + }
log.error("Exception occured during execute push on " + viewID, e);
throwRenderingException(e);
} finally {
@@ -289,7 +291,9 @@
String viewID = "Unknown View";
try { viewID = facesContext.getViewRoot().getViewId(); - }
catch (NullPointerException npe) { }
+ } catch (NullPointerException npe)
log.error("Exception occured during execute push on " + viewID, e);
throwRenderingException(e);
}
It may not be possible to completely eliminate this Exception since it is logged by JSF and is not detectable until ICEfaces attempts to operate on a View that is no longer restorable by Seam.
Show
Ted Goddard
added a comment - The following change results in just one Exception being logged, not a series:
+++ src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java (working copy)
@@ -177,7 +177,9 @@
String viewID = "Unknown View";
try
{
viewID = facesContext.getViewRoot().getViewId();
- } catch (NullPointerException npe) { }
+ } catch (NullPointerException npe) {
+ view.dispose();
+ }
log.error("Exception occured during execute push on " + viewID, e);
throwRenderingException(e);
} finally {
@@ -289,7 +291,9 @@
String viewID = "Unknown View";
try {
viewID = facesContext.getViewRoot().getViewId();
- }
catch (NullPointerException npe) { }
+ } catch (NullPointerException npe)
{
+ view.dispose();
+ }
log.error("Exception occured during execute push on " + viewID, e);
throwRenderingException(e);
}
It may not be possible to completely eliminate this Exception since it is logged by JSF and is not detectable until ICEfaces attempts to operate on a View that is no longer restorable by Seam.
Tyler's note from 18/11/2011
Using nwf-sample-Nov08.war as mentioned before I get into this 302 redirect loop. However, when I just take out the EPS configuration in the web.xml things started working. Then I discovered that eps-jms.jar was missing from the nwf-sample-Nov08.war. Adding that in and enabling the EPS configuration again, I got it to work. Strange that not having that .jar in there results in a 302 redirect loop initiated by Seam.
Without eps-jms.jar, the application will display the source to the Facelet page rather than the HTML output.
Show
Ted Goddard
added a comment - Tyler's note from 18/11/2011
Using nwf-sample-Nov08.war as mentioned before I get into this 302 redirect loop. However, when I just take out the EPS configuration in the web.xml things started working. Then I discovered that eps-jms.jar was missing from the nwf-sample-Nov08.war. Adding that in and enabling the EPS configuration again, I got it to work. Strange that not having that .jar in there results in a 302 redirect loop initiated by Seam.
Without eps-jms.jar, the application will display the source to the Facelet page rather than the HTML output.
| Salesforce Case | [5007000000JM4Y0] |
| Field | Original Value | New Value |
|---|---|---|
| Attachment | 10630_log_March21.txt [ 14233 ] |
From mojarra Phase.java
} catch (Exception e) {
{ this.getId().toString(), ((context.getViewRoot() != null) ? context.getViewRoot().getViewId() : ""), event}if (LOGGER.isLoggable(Level.SEVERE)) {
LOGGER.log(Level.SEVERE,
"jsf.lifecycle.phase.exception",
new Object[]
);
}
ex = e;
} finally {
Any Exception that occurs during execution is logged, and ICEfaces has no way of knowing that the view cannot be restored prior to attempting the view restoration, so the other alternative would be to disable SEVERE logging on com.sun.faces.lifecycle.Phase.