Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1237275

Summary: [GSS](6.4.z) CLI does not allow to use multiple property substitution in the same element or address
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Jyoti Wankhede <jwankhed>
Component: CLIAssignee: Tomas Hofman <thofman>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Kremensky <pkremens>
Severity: high Docs Contact:
Priority: high    
Version: 6.4.0CC: bmaxwell, brian.stansberry, cdewolf, harshada, istudens, jboss-set, mkopecky, sjadhav, thofman
Target Milestone: CR1Keywords: Reopened
Target Release: EAP 6.4.3   
Hardware: All   
OS: All   
URL: https://github.com/jbossas/jboss-eap/pull/2477
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-17 10:45:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1231259, 1289316    

Description Jyoti Wankhede 2015-06-30 17:17:59 UTC
Description of problem:
=======================

CLI is not substituting the second property in the elements name for example in the following CLI command:
--------
/profile=${PROFILENAME}${APPVERSION}:add()
--------

Even after setting "<resolve-parameter-values>" property to true, the behaviour is not as expected. The above command is setting the following value in domain.xml:
--------
<profile name="profile1${APPVERSION}"/>
--------
Here it means only the first property substitution is done, but the second property is not being replaced by its value.


Version-Release number of selected component (if applicable):
=============================================================
EAP 6.4.0 and EAP 6.4.1 as well as I have tested this behaviour in both the version. 

How reproducible:
=================
Following are the steps to reproduce.

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

1) Created a properties file "my.properties" like this:
--------------
PROFILENAME=profile1
APPVERSION=-ver1
--------------

2) Created a .cli file "AddProfile.cli" like this:
---------------
if (outcome != success) of /profile=${PROFILENAME}${APPVERSION}:read-resource
  /profile=${PROFILENAME}${APPVERSION}:add()
end-if
---------------


3) Set the value of "<resolve-parameter-values>" property to "true" in the jboss-cli.xml.

4) Then executed the following command:
---------------
./jboss-cli.sh -c --file=AddProfile.cli --properties=my.properties
---------------

The above CLI command adds the following configuration in the domain.xml:
---------------
    <profile name="profile1${APPVERSION}"/>
---------------


Actual results:
===============
CLI command "/profile=${PROFILENAME}${APPVERSION}:add()" is setting the following value in domain.xml:
--------
<profile name="profile1${APPVERSION}"/>
--------

Expected results:
=================
CLI command "/profile=${PROFILENAME}${APPVERSION}:add()" should set the following value in domain.xml:
--------
<profile name="profile1-ver1"/>
--------

Additional info:
================
This behaviour is same in the EAP 6.4.1 as well.


Workaround:
===========
Following shell script can be used as a workaround for achieving above kind of property isolation in CLI commands.

testcli.sh:
-----------
#!/bin/sh
. /PATH-UP-TILL/my.properties
$JBOSS_HOME/bin/jboss-cli.sh --connect <<EOF
if (outcome != success) of /profile=${PROFILENAME}${APPVERSION}:read-resource
  /profile=${PROFILENAME}${APPVERSION}:add()
end-if
exit
EOF
-----------

The above shell script uses the property file and substitutes the property's values as expected. for example in this case:
-----------
<profile name="profile1-ver1"/>
-----------

Comment 5 Tomas Hofman 2015-07-08 14:25:37 UTC
PR: https://github.com/jbossas/jboss-eap/pull/2477

Comment 6 Rostislav Svoboda 2015-07-09 11:08:09 UTC
Thank you for the tests in PR.

Comment 7 Marek Kopecky 2015-07-30 11:32:07 UTC
Verified on EAP 6.4.3.CP.CR1

Comment 10 Petr Penicka 2017-01-17 10:41:47 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Comment 11 Petr Penicka 2017-01-17 10:42:17 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.

Comment 12 Petr Penicka 2017-01-17 10:45:51 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.