Bug 818761 - "Unable to re-install or upgrade server on same host and port due to 404 /coregui/ not found"
"Unable to re-install or upgrade server on same host and port due to 404 /cor...
Product: JBoss Operations Network
Classification: JBoss
Component: Documentation (Show other bugs)
JON 3.1.0
Unspecified Unspecified
urgent Severity high
: DR01
: JON 3.3.0
Assigned To: Jay Shaughnessy
Mike Foley
: 640212 (view as bug list)
Depends On:
Blocks: jon310-sprint11/rhq44-sprint11 820736
  Show dependency treegraph
Reported: 2012-05-03 17:13 EDT by Mike Foley
Modified: 2014-10-23 08:26 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 820736 (view as bug list)
Last Closed: 2014-06-06 10:57:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike Foley 2012-05-03 17:13:33 EDT
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 ..


Open the web UI.

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.
Comment 1 Larry O'Leary 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.
Comment 2 John Mazzitelli 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?
Comment 3 Jay Shaughnessy 2012-05-10 10:03:16 EDT
*** Bug 640212 has been marked as a duplicate of this bug. ***
Comment 4 Jay Shaughnessy 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 5 Jay Shaughnessy 2012-05-10 16:14:50 EDT
A fix has been committed for the upstream BZ.  Awaiting verification.
Comment 6 Larry O'Leary 2012-05-11 16:41:23 EDT
Captured documentation task Bug 821093 to identify this as a Known Issue seeing that even with this fix, the problem will exist for previous installations.
Comment 7 Jay Shaughnessy 2012-05-21 11:42:57 EDT
Cherry pick from master: Commit c321a60e4e828fa6a538d08ed9198dc83ace130b

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