An issue with the *Deployment Name* being read-only after initial discovery meant that changing a WAR or EAR deployment from exploded to unexploded (or vice versa) after it was initially deployed resulted in the resource always being DOWN or Unavailable. It was not possible to monitor or manage the resource. The fix removes connection setting's "deploymentName" attribute and adds the "deploymentKey attribute. The attribute is only loaded when the component is started, or when it goes down because of NoSuchDeployment. Improvements to the Refresh button on the Monitoring/Calltime page are also implemented as part of this fix.
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>
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
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>
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.
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.