Red Hat Bugzilla – Bug 885848
Changing WAR/EAR deployment from exploded to unexploded (or vice versa) results in resource always being DOWN/Unavailable
Last modified: 2014-12-11 09:00:27 EST
Description of problem: WAR is always DOWN and can not be monitored or managed if its deployment type (exploded or unexploded) changes after its initial discovery. Version-Release number of selected component (if applicable): 4.4.0.JON311GA How reproducible: Always Steps to Reproduce: 1. Create unexploded admin-console.war using files in deploy/admin-console.war/ cd <JBOSS_SERVER_HOME>/deploy/admin-console.war/ zip -r ../admin-console.war.zip . cd .. rm -rf admin-console.war mv admin-console.war.zip admin-console.war 2. Start EAP server 3. Start ON system 4. Import EAP server into inventory 5. Verify that admin-console.war has a *Deployment Name* starting with `vfszip:` 6. Shutdown EAP 7. Redeploy admin-console.war in an exploded form cd <JBOSS_SERVER_HOME>/deploy/ unzip admin-console.war -d admin-console.war.dir rm -f admin-console.war mv admin-console.war.dir admin-console.war 8. Start EAP 9. Force service/detail discovery from agent Actual results: admin-console.war shows a state of DOWN Expected results: admin-console.war shows as state of UP Additional info: This is due to the *Deployment Name* being read-only/static after initial discovery. When the WAR is redeployed in an exploded form, the deployment ID changes in EAP to reflect vfsfile: instead of vfszip:. This change results in the already inventoried resource failing to locate the managed component in the management view due to the subtle ID change. Because it is not uncommon for a deployment to change from exploded to unexploded or vice versa, and this is supported and expected within JBoss AS/EAP, this should be addressed either by service discovery itself or via a method to update the *Deployment Name* property in those rare cases that this would be necessary.
Fixed in master commit 54ce392a7e2e8cc58718102f3e3af60d0ef64ab1 Author: Thomas Segismont <tsegismo@redhat.com> Date: Thu Sep 18 11:23:01 2014 +0200 Removed connection settings "deploymentName" attribute Added connection settings "deploymentKey attribute (upgraded from "deploymentName") We don't need to know if the deployment points to a "vfsfile:/" or "vfszip:/" Now the profile service "deploymentName" is lazily loaded when the component is started or when it goes down because of NoSuchDeployment Tested with EAP5.1.2 on WAR and EAR. -> Deploy new package OK -> Delete resource OK -> Restart application OK
branch: release/jon3.3.x link: https://github.com/rhq-project/rhq/commit/5ad0d9836 time: 2014-09-24 14:11:50 +0200 commit: 5ad0d98367ab0e3d67d4cea853e2a85639c69340 author: Thomas Segismont - tsegismo@redhat.com message: Bug 1032054 - Refresh button on Monitoring/Calltime page does not move 'last 8 hour' time range Make CalltimeView implement the refresh mechanism instead of CalltimeTableView The problem was that #refresh was defined both in Table class and AutoResfresh interface. (cherry picked from commit 945aeb12cbf8bb3e382d1d222ad54ae1f8f960cf) Signed-off-by: Libor Zoubek <lzoubek@redhat.com>
Moving to ON_QA as available for test with build: https://brewweb.devel.redhat.com/buildinfo?buildID=388959
Verified on JON 3.3 ER04 Followed the steps and verified that admin-console.war connection settings does not have"deploymentName" attribute. It shows the 'Deployment Key. property. After final step verified that admin-console.war is up and operations like stop, start, restart are successful on EAP resource.