Bug 667896 - Calculating Dynamic Group with more than one trait in Group Definition Condition causes Hibernate Exception
Calculating Dynamic Group with more than one trait in Group Definition Condit...
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
All All
high Severity high (vote)
: ---
: RHQ 4.5.0
Assigned To: John Sanda
Mike Foley
: 835955 (view as bug list)
Depends On:
Blocks: 826716 837078
  Show dependency treegraph
Reported: 2011-01-07 02:16 EST by Myee Riri
Modified: 2013-09-01 06:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 826716 (view as bug list)
Last Closed: 2013-09-01 06:03:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
log snippet (10.23 KB, application/octet-stream)
2011-01-07 02:16 EST, Myee Riri
no flags Details

  None (edit)
Description Myee Riri 2011-01-07 02:16:49 EST
Created attachment 472190 [details]
log snippet

Description of problem:

When calculating a dynamic group definition with more than one trait in the conditions a hibernate exception occurs. No group members are found.

Version-Release number of selected component (if applicable):
JON 2.4
EAP Plugins
SOAP Plugins
EWS Plugins
JDK 1.6 U23

Steps to Reproduce:
1. Create a new Group Definition
2. Enter the following as the conditions

resource.grandParent.trait[Trait.hostname].contains = stage
resource.parent.type.plugin = JBossAS5
resource.type.name = Web Application (WAR)
resource.trait[contextRoot] = jmx-console

Note: just using the jmx-console as an example, it won't matter what the context root is (unless it is blank because / as context root is not handled and throws the following syntax error:

Syntax error in your group definition: Expression must be in one of the follow forms: 'groupBy condition', 'condition = value', 'empty condition', 'not empty condition 


3. Save group
4. Calculate group members
Actual results:
In the UI:
There was a problem calculating the results: java.lang.IllegalArgumentException: org.hibernate.QueryParameterException: could not locate named parameter [arg2] 

In the Log: 
ERROR [org.rhq.enterprise.server.resource.group.definition.GroupDefinitionManagerBean] Error recalculating DynaGroups for GroupDefinition[id=10011]
javax.ejb.EJBException: java.lang.IllegalArgumentException: org.hibernate.QueryParameterException: could not locate named parameter [arg2]

see attached for relevant stack trace

Expected results:
Find all deployed jmx-console Web Applications for JBossAS 5 profiles on servers with "stage" in the hostname

Additional info:
It will find all Web Applications for JBossAS 5 profiles on servers with "stage" in the hostname if I remove the last line - so I think the condition is valid.

This also occurs when other group definitions with more than one trait in the conditions.
Comment 2 John Sanda 2012-06-22 15:51:28 EDT
After some investigation it looks like the expression parsing code was implementing in a way that never supported multiple traits; furthermore, this does not appear to be limited just to traits. For example, I generate the same exception with,

resource.type.plugin = RHQAgent
resource.type.name = Plugin Container
resource.type.plugin = RHQAgent
resource.type.name = Garbage Collector

I need to do some more investigation, but at this point I think we can treat this in one of two ways. Either treat as an RFE to support multiple conditions of the same type, or we say that these expressions are invalid and we need better error reporting to indicate as such.
Comment 3 John Sanda 2012-06-25 17:29:29 EDT
I have done some more investigation and have come to the conclusion that there would be a substantial amount of effort required to support these enhancements. First we would need to understand and identify what new types of JPQL queries would have to be generated. Based on my investigation and discussions with Jay Shaughnessy, I am not clear what those queries would look like. Next we would have to figure out how to implement the new functionality. ExpressionEvaluator is the primary class involved. It is designed across the board to only handle one resource expression for each type of supported expression. The supported types include:

* resource.id 
* resource.name 
* resource.version 
* resource.type.plugin 
* resource.type.name 
* resource.type.category 
* resource.availability
* resource.pluginConfiguration[<property-name>] 
* resource.resourceConfiguration[<property-name>] 
* resource.trait[<property-name>]

Lastly, a substantial amount of testing would be required to make sure that the new functionality behaves as expected and more importantly, to ensure no regressions are introduced. We also would need to take into consider the performance impact of the changes as the queries would likely be expensive operations.

I will proceed with changes for improved error handling. I will also open a docs bug to make sure we documented expressions that are and are not supported. If we do want to make these enhancements, I would prefer to track that effort under a separate RFE bug.
Comment 4 John Sanda 2012-06-26 11:06:01 EDT
The supported types listed in comment 3 did not include all the different resource context combinations which include,

* resource.child
* resource.parent
* resource.grandParent
* resource.greatGrandParent
* resource.greatGreatGrandParent
Comment 5 John Sanda 2012-06-27 11:59:24 EDT
While writing unit tests for the code involved, I discovered another scenario that is not supported. You can only have one plugin configuration expression or one resource configuration expression but not both. For example, the following will result in an exception similar to the one in the original description,

resource.pluginConfiguration[x] = foo
resource.resourceConfiguration[y] = bar

The reason for this is that the same alias is used for both plugin config and resource config properties in the generated JPQL query. Since this is a slightly different issue, I will open a separate bug to track this. This is something that could and should be fixed independent of this bug.
Comment 6 John Sanda 2012-07-02 11:47:48 EDT
I have added unit tests that cover all of the different resource expression combinations to verify that an exception is thrown. I have also updated the UI to provide better error reporting. Since this an exception that can be handled, we no longer propagate a stack trace to the UI. We instead report an error message like, "You cannot specify multiple trait expressions." Changes have been pushed to master.

commit hashes:
* 3442a828a
* 95a0bf5b8be
* c97c6b90b7
* 25b62b50ad
Comment 7 John Sanda 2012-07-02 13:24:32 EDT
*** Bug 835955 has been marked as a duplicate of this bug. ***
Comment 8 John Sanda 2012-07-02 13:28:50 EDT
Part of what I said in comment 5 is not entirely accurate. While it is a slightly separate issue since it involves different expression types, the problems are still the because plugin configuration and resource configuration expressions result in querying the same set of tables.
Comment 9 John Sanda 2012-07-08 14:29:06 EDT
I opened bug 837078 as a docs bug to make more clear that multiple expressions of the same type are illegal. The issue described in comment 5 involving resource and plugin config expressions was logged as bug 835955; however, I wound up closing 835955 since it is the same root issue as this bug. While it involves different expression types, it involves the same entities and tables.
Comment 10 Heiko W. Rupp 2013-09-01 06:03:08 EDT
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.

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