Bug 534592 - (RHQ-1374) using tree with stale session causes 500 error
using tree with stale session causes 500 error
Status: CLOSED NEXTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
unspecified
All All
medium Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
http://jira.rhq-project.org/browse/RH...
: SubTask
Depends On:
Blocks: RHQ-1267 RHQ-1470
  Show dependency treegraph
 
Reported: 2009-01-16 16:22 EST by Charles Crouch
Modified: 2015-02-01 18:24 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2009-01-16 16:22:00 EST

    
Comment 1 Charles Crouch 2009-01-16 16:24:15 EST
Steps to reproduce

1) Go to the monitor tab for a resource
2) wait for your session to expire
3) click on a node in the nav tree on the left
4) when prompted enter your credentials again
5) get a 500 error...

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: viewId:/rhq/resource/monitor/tables.xhtml - View /rhq/resource/monitor/tables.xhtml could not be restored.
	javax.faces.webapp.FacesServlet.service(FacesServlet.java:270)
	org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177)
	org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)
	org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)
	org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)
	org.rhq.enterprise.gui.legacy.AuthenticationFilter.doFilter(AuthenticationFilter.java:129)
	org.rhq.enterprise.gui.common.upload.MultipartFilter.doFilter(MultipartFilter.java:63)
	org.rhq.helpers.rtfilter.filter.RtFilter.doFilter(RtFilter.java:116)
	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

root cause

javax.faces.application.ViewExpiredException: viewId:/rhq/resource/monitor/tables.xhtml - View /rhq/resource/monitor/tables.xhtml could not be restored.
	com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:186)
	com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
	com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
	com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
	javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
	org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177)
	org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)
	org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)
	org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)
	org.rhq.enterprise.gui.legacy.AuthenticationFilter.doFilter(AuthenticationFilter.java:129)
	org.rhq.enterprise.gui.common.upload.MultipartFilter.doFilter(MultipartFilter.java:63)
	org.rhq.helpers.rtfilter.filter.RtFilter.doFilter(RtFilter.java:116)
	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

note The full stack trace of the root cause is available in the JBossWeb/2.0.0.GA logs.
Comment 2 Joseph Marques 2009-01-19 20:04:36 EST
i thought i fixed this a while back, but i guess the solution wasn't overarching enough.  i'll fix this properly this time.
Comment 3 Joseph Marques 2009-01-23 04:18:35 EST
rev2715 - fix the ViewExpiredException once and for all; 
you will now be redirected back to the URL you were on just before it was thrown; 
Comment 4 Joseph Marques 2009-01-23 04:23:03 EST
for testing, open the following file:

jbossas/server/default/deploy/rhq.ear/rhq-portal.war/WEB-INF/web.xml

change:

   <session-config>
      <session-timeout>30</session-timeout>
   </session-config>

to:

   <session-config>
      <session-timeout>1</session-timeout>
   </session-config>

this will expire the user's session after 1 minute, to facilitate quick testing.  go to some JSF page, say the operations tab for some resource.  select some operation to execute, but don't click the "execute" button yet.  wait one minute for the session to time out.  

now click the "execute" button.  you should be redirected to the login page first because you have no session anymore and the operations tab url is a "secure" url requiring a logged in.  once you log in, you should be on the SAME page you were before.  you'll need to click the button again, but this is A LOT better than getting a nasty stack trace.
Comment 5 Red Hat Bugzilla 2009-11-10 15:31:34 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1374

Note You need to log in before you can comment on or make changes to this bug.