Bug 820736

Summary: "Unable to re-install or upgrade server on same host and port due to 404 /coregui/ not found"
Product: [Other] RHQ Project Reporter: Jay Shaughnessy <jshaughn>
Component: Core UI, InstallerAssignee: Jay Shaughnessy <jshaughn>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: urgent    
Version: 4.4CC: hrupp, jshaughn, loleary, mazz, mfoley, rtimaniy
Target Milestone: ---   
Target Release: RHQ 4.5.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 818761 Environment:
Last Closed: 2013-09-01 10:15:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 818761    
Bug Blocks: 782579    

Description Jay Shaughnessy 2012-05-10 20:10:02 UTC
+++ This bug was initially created as a clone of Bug #818761 +++

Description of problem:  "Unable to re-install or upgrade server on same host and port due to 404 /coregui/ not found"


Specifically ... step #11 on this document ..


http://docs.redhat.com/docs/en-US/JBoss_Operations_Network/3.0/html/Installation_Guide/upgrading.html

Says:
Open the web UI.
http://hostname:7080

But the redirection is not happening.

This happens to me all the time on install ... and will affect customers on install and upgrade.  I have become sort of numb and desensitived to it ... and just enter the /welcome.jsf and /coregui on my URI ... but this is not in the doc.

--- Additional comment from loleary on 2012-05-03 17:17:31 EDT ---

This is a result of browser caching a redirect:

http://localhost:7080/   --->  http://localhost:7080/coregui/


So, once a server is installed and the browser goes to http://localhost:7080 and gets redirected to http://localhost:7080/coregui/ it can never be redirected to http://localhost:7080/installer/welcome.jsf (which is what is supposed to happen on first install) due to the cached redirect.

--- Additional comment from mazz on 2012-05-09 09:38:50 EDT ---

i'm pretty sure we send the no-cache HTTP headers in the installer jsp pages, but maybe not all of them that all browsers honor. Anyone know which no-cache HTTP headers we should ensure we send to get this to not be cached?

--- Additional comment from jshaughn on 2012-05-10 10:03:16 EDT ---

*** Bug 640212 has been marked as a duplicate of this bug. ***

--- Additional comment from jshaughn on 2012-05-10 10:26:18 EDT ---


I may end up giving this back, I'm not very sure about this stuff.

Here's what seems to be happening, starting with a clean browser cache:

1) Unzip RHQ and start it.

2) http://localhost:7080/ will bring you to the installer because:

   - ROOT.war web.xml sets its welcome-file to index.html
   - which sends you to /installer/welcome.jsf
   - it also specifies no-cache

3) You perform the install and it deploys rhq.ear:

   - in application.xml we set portal.war as the context root
   - portal war sets its welcome file to its index.html
   - the index.html redirects to /coregui/ (via meta refresh with a 0 interval)

I think maybe this can get cached.  So, perhaps if we add no-cache to
portal-war's index.html we'll be ok.  So, if rhq.ear/portal-war are not running, like when we're upgrading, that the installer would again get precedence.

Worth a try...

Comment 1 Jay Shaughnessy 2012-05-10 20:13:55 UTC
master commit d770be2d295922c2a67054e5fe8c309a533f3e35

An attempt at fixing this by not caching portal wars index.html.



Test Notes:
This change seemed to do the trick in my testing.  When testing, make sure you
start by clearing the browser cache then proceed to the first install.  This
will not solve the issue for browsers already caching the redirect. That has to
be cleared manually. It should solve the issue going forward.

Comment 2 Heiko W. Rupp 2013-09-01 10:15:40 UTC
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.