Bug 1007696 - [GSS] (6.2.x) CLI fails to show app status when runtime-name is different from the deployment name
[GSS] (6.2.x) CLI fails to show app status when runtime-name is different fro...
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
6.0.1
All All
unspecified Severity medium
: CR1
: EAP 6.2.1
Assigned To: Brian Stansberry
Petr Kremensky
Russell Dickenson
:
Depends On: 1049102
Blocks: eap62-cp01-blockers
  Show dependency treegraph
 
Reported: 2013-09-13 03:10 EDT by Jay SenSharma
Modified: 2015-07-19 20:59 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When the runtime name of an application was different to the name of the EAR, the management CLI would fail to show the status of the application, returning instead the message "No metrics available.". The cause of this issue was that the management CLI queried the application by the name of the EAR and since this was different to the name of the EAR, a match could not be found. To resolve this issue, the search is now conducted by the application's runtime. As a result, CLI operations are now successful even if the runtime name does not match the name of the EAR.
Story Points: ---
Clone Of:
: 1049102 (view as bug list)
Environment:
Last Closed: 2014-02-24 15:14:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-2061 Major Resolved CLI fails to show app status when runtime-name is different from the deployment name 2015-07-20 20:56:36 EDT

  None (edit)
Description Jay SenSharma 2013-09-13 03:10:32 EDT
Description of problem:
==================
If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.


Version-Release number of selected component (if applicable):


How reproducible: Yes

Steps to Reproduce:
==================

Step1). Deploy an application with a different --name and --runtime-name as following:

[domain@localhost:9999 /] deploy /home/ABC.ear --name=ABC.ear --runtime-name=XYZ.ear --server-groups=main-server-group

Step2). Now try to see the status of an application then it is showing "no metrics available".

[domain@localhost:9999 /] /host=master/server=server-one/deployment=ABC.ear:read-attribute(name=status)
{ "outcome" => "success", "result" => "no metrics available" }


Actual results:
===============
Where as if the --name and the --runtime-name is dame then the application status is shown properly as "OK"


Expected results:
===============
{ "outcome" => "success", "result" => "OK" }

Additional info:
Comment 1 Jay SenSharma 2013-09-13 03:15:34 EDT
- According to the "runtime-name" description the users should be allowed to choose a different runtime-name for their deployments.

- "description" =>  "Name by which the deployment should be known within a server's runtime. This would be equivalent to the file name of a deployment file, and would form the basis for such things as default Java Enterprise Edition application and module names. This would typically be the same as 'name', but in some cases users may wish to have two deployments with the same 'runtime-name' (e.g. two versions of \"foo.war\") both available in the deployment content repository, in which case the deployments would need to have distinct 'name' values but would have the same 'runtime-name'."
Comment 2 JBoss JIRA Server 2013-09-13 09:21:53 EDT
Karsten Jorgensen <karjoe@rm.dk> made a comment on jira WFLY-2061

If the "name" is not identical to the "runtime-name", it is also not possible to check statistics like the number of instances of some session bean. I don't know if the root cause of this is the same as the root cause of not being able to check the application status?
Comment 8 Nikoleta Ziakova 2014-01-24 04:01:17 EST
Verified with 6.2.1.CP.CR1-patch.

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