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):
Steps to Reproduce:
1. Create unexploded admin-console.war using files in deploy/admin-console.war/
zip -r ../admin-console.war.zip .
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
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
admin-console.war shows a state of DOWN
admin-console.war shows as state of UP
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
Author: Thomas Segismont <firstname.lastname@example.org>
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
time: 2014-09-24 14:11:50 +0200
author: Thomas Segismont - email@example.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
The problem was that #refresh was defined both in Table class
and AutoResfresh interface.
(cherry picked from commit
945aeb12cbf8bb3e382d1d222ad54ae1f8f960cf) Signed-off-by: Libor
Moving to ON_QA as available for test with build:
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.