look at the attached snapshot.
I have 1 linux platform, 2 windows. Each agent is managing a JBossAS server. I therefore have 1 run.sh and 2 run.bat scripts:
id resource_type_id name resource_key
500606 501077 run.bat C:\mazz\source\rhq\trunk\dev-container\jbossas\bin\run.bat
500852 501077 run.bat C:\mazz\source\rhq\trunk\dev-container\jbossas\bin\run.bat
501072 501077 run.sh /home/mazz/jboss/jboss-eap-4.3/jboss-as/bin/run.sh
Clicking the auto-group of "run.bat (2/3)" shows a table of 0 resources (the right side is empty).
Clicking the auto-group of the "run.sh (1/3)" shows the correct table of 1 resource.
for the record, resource type ID of 501077 is:
id name category creation_data_type create_delete_policy singleton supports_manual_add description plugin ctime mtime subcategory_id plugin_config_def_id res_config_def_id
501077 Script SERVICE CONFIGURATION NEITHER false true provides the ability to execute a script that performs some task related to its parent JBossAS server JBossAS 1239944619687 1239944619750 500050 501619 (null)
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1986
Imported an attachment (id=368720)
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.
new = Tracking + FutureFeature + SubBug
making sure we're not missing any bugs in rhq_triage
i need to check to see if this is still happening in gwt
the problem is that the resource keys contain backslashes (Windows strikes again!)
The resource keys for the scripts are the full paths such as:
But the query we build up doesn't escape the path, which we include hardcoded in the query - here's is an actual example of the query we execute, notice the resource key enclosed in single quotes:
SELECT r1 FROM Resource r1
WHERE r1.resourceKey = 'C:\jboss-as\bin\run.bat'
AND r1.resourceType = 10147
AND r1.parentResource IN ( SELECT rgir
FROM ResourceGroup rg
JOIN rg.implicitResources rgir
WHERE rg = 10121)
When I replace that key string such that its backslashes are escaped (that is "\\" instead of "\"), the query returns the proper results.
Unsure if Oracle requires the escape characters, but we should probably change these queries to use :param parameters so we don't have to worry about escaping characters.
we now use :param notation to pass in the resource key parameters, rather than hardcoding them. this works around any need we would have had to escape characters in the hardcoded resource keys
tested RHQ Master ...using Oracle repository. Confirmed by using SQL to verify that RHQ_RESOURCE table contains data with slashes "/" ... and using DEBUG level logging that no errors in SQL execution. I have been performing numerous qualifications since the bug fix 3/11 and this is fine.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.