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.
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.
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.
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
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.
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
*** Bug 835955 has been marked as a duplicate of this bug. ***
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.
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.
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.