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.
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.
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?
*** Bug 640212 has been marked as a duplicate of this bug. ***
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...
A fix has been committed for the upstream BZ. Awaiting verification.
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.
Cherry pick from master: Commit c321a60e4e828fa6a538d08ed9198dc83ace130b