Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Won't Fix
-
Affects Version/s: 3.3
-
Fix Version/s: EE-3.3.0.GA, 4.0.BETA, 4.0
-
Labels:None
-
Environment:JBoss 6, CDI, Weld
-
Assignee Priority:P1
-
Salesforce Case Reference:
-
Workaround Exists:Yes
-
Workaround Description:HideAs noted in the case, it's possible to handle the CDI exception from the client using either the JSF or ICE API for error handling.
It's also possible to make your own ExceptionHandler that can either remove the exception and let the SessionExpiredException propagate to the client so that the redirect behaves normally or handle the error in some other way.ShowAs noted in the case, it's possible to handle the CDI exception from the client using either the JSF or ICE API for error handling. It's also possible to make your own ExceptionHandler that can either remove the exception and let the SessionExpiredException propagate to the client so that the redirect behaves normally or handle the error in some other way.
Description
-
Hide
- 12134.war
- 7.23 MB
- Arran Mccullough
-
- META-INF/MANIFEST.MF 0.1 kB
- login.xhtml 0.7 kB
- nada.xhtml 0.5 kB
- WEB-INF/.faces-config.xml.jsfdia 0.1 kB
- WEB-INF/beans.xml 0.2 kB
- WEB-INF/classes/.../BackingBean.class 0.7 kB
- WEB-INF/classes/fi/.../concept/Filter.class 2 kB
- WEB-INF/classes/.../concept/Listener.class 1 kB
- WEB-INF/faces-config.xml 0.3 kB
- WEB-INF/jboss-web.xml 0.1 kB
- WEB-INF/lib/commons-beanutils-1.8.0.jar 226 kB
- WEB-INF/lib/FastInfoset-1.2.12.jar 287 kB
- WEB-INF/lib/icefaces-3.3.0-RC1.jar 579 kB
- WEB-INF/lib/icefaces-ace-3.3.0-RC1.jar 4.00 MB
- WEB-INF/.../icefaces-compat-3.3.0-RC1.jar 2.59 MB
- WEB-INF/lib/icepush-3.3.0-RC1.jar 194 kB
- WEB-INF/web.xml 2 kB
- META-INF/maven/.../Concept2/pom.xml 3 kB
- META-INF/maven/.../Concept2/pom.properties 0.1 kB
-
Hide
- 12134-mod.war
- 15 kB
- Deryk Sinotte
-
- META-INF/MANIFEST.MF 0.1 kB
- META-INF/maven/.../Concept2/pom.properties 0.1 kB
- META-INF/maven/.../Concept2/pom.xml 3 kB
- WEB-INF/.faces-config.xml.jsfdia 0.1 kB
- WEB-INF/beans.xml 0.2 kB
- WEB-INF/classes/.../BackingBean.class 0.7 kB
- WEB-INF/classes/fi/.../concept/Filter.class 2 kB
- WEB-INF/classes/.../concept/Listener.class 1 kB
- WEB-INF/.../NoConversationExceptionHandler.class 3 kB
- WEB-INF/.../NoConversationExceptionHandlerFactory.class 1.0 kB
- WEB-INF/faces-config.xml 0.5 kB
- WEB-INF/jboss-web.xml 0.1 kB
- WEB-INF/lib/.DS_Store 6 kB
- WEB-INF/web.xml 2 kB
- login.xhtml 3 kB
- nada.xhtml 0.5 kB
- src/.DS_Store 6 kB
- src/.../NoConversationExceptionHandler.java 3 kB
- src/.../NoConversationExceptionHandlerFactory.java 0.6 kB
- web/index.jsp 0.2 kB
- web/WEB-INF/jboss-web.xml 0.2 kB
- web/WEB-INF/web.xml 0.3 kB
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Attaching a modified version of the test case that shows the ExceptionHandler strategy. Source has been included but the libs have been removed to reduce the size.
Since this is not currently seen as a generic solution, we're going to leave it as something for application developers to use. Another case (ICE-9234) has been opened to potentially add a feature for more generic handling for exceptions from Ajax responses.
(Case owner commenting)
I've used option 2 before but I considered it more of handling a side effect (NonexistingConversationException) than the actual session expiring, I'll give option 1 a spin. What should the web.xml parameters for disabling default popups be for option 1 and 2.
What I find slightly confusion is that Weld activates the non-transient conversation in a PhaseListener but even if I activate the Filter I have in the original WAR, I can detect the stale session and redirect before the exception is thrown but redirect is still ignored.
The following context parameter can be used to disable the default error popups:
<context-param>
<param-name>org.icefaces.disableDefaultErrorPopups</param-name>
<param-value>true</param-value>
</context-param>
http://www.icesoft.org/wiki/display/ICE/disableDefaultErrorPopups
The ICEfaces client-side bridge is looking for a very specific Ajax response to do the redirect. It must be an error containing org.icefaces.application.SessionExpiredException. If anything else arrives as the Ajax response, the redirect does not get triggered. That's why I've created the new case as a potential improvement to allow more flexible error handling on the client.
I'm not a Weld/CDI expert so I'm not sure about all the conditions that cause NonexistingConversationException to occur so it's best at this point to handle it in the application. I still think option 2 is a legitimate solution as well. It's the mechanism that JSF provides for handling errors triggered via Ajax requests.
Attached test case that shows the issue. It is setup to run on Jboss EAP 6.1.0 and is compiled using JDK7.
Steps: