Bug 594516 - search: group definitions parameterized filters are too strict
Summary: search: group definitions parameterized filters are too strict
Alias: None
Product: RHQ Project
Classification: Other
Component: Core Server
Version: 3.0.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Joseph Marques
QA Contact: Corey Welton
Depends On:
Blocks: jon-sprint11-bugs
TreeView+ depends on / blocked
Reported: 2010-05-20 21:46 UTC by Joseph Marques
Modified: 2010-08-12 16:46 UTC (History)
2 users (show)

Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-12 16:46:15 UTC

Attachments (Terms of Use)

Description Joseph Marques 2010-05-20 21:46:58 UTC
Description of problem:

When you search using things like trait[foo], it will search for "foo" exactly.  We probably want this to be a substring match by default.

How reproducible:

Every time.

Steps to Reproduce:
1. Inventory some SOA servers with the "production" config set active
2. Create group def with "groupby resource.trait[partitionName]"
3. Calculate the membership
Actual results:

No dynagroup children created

Expected results:

One dynagroup child created, with the single SOA server in it, with it's partitionName (something like "SOADomain" by default)

Additional info:

Root of the problem is that the SOA trait is not simply "partitionName", it is actually "MCBean|ServerConfig|*|partitionName".  If we implement substring matching for parameterized values inside '[' amd ']', then it would find EAP and SOA servers.  Users could still use other expressions to either filter the results further or create more/smaller subgroups.

Comment 1 Charles Crouch 2010-06-15 21:56:05 UTC
(11:03:06 AM) uaarkoti: ccrouch: the problem with 594516 is that if a customer is running EAP 5, they cannot create a group definition to group them dynamically. It might be ok to create a compatible group and add the instances manually but if there are large deployments its a pain.
(11:05:20 AM) ccrouch: uaarkoti: is 594516 a regression from 2.3.1 ?
(11:05:58 AM) uaarkoti: ccrouch: Yes

Comment 2 Charles Crouch 2010-06-15 21:57:50 UTC
Ignore that needinfo flag

Comment 3 Udaypal Aarkoti 2010-06-16 01:53:39 UTC
Just want to clarify my comment earlier. Since the

Comment 4 Udaypal Aarkoti 2010-06-16 01:54:48 UTC
partitionName is not set, creating a group definition to group based on partition name results in no groups.

Comment 5 Joseph Marques 2010-06-16 05:36:12 UTC
commit 823e1f291747019a3a15e8d47cdee1f56421b133
Author: Joseph Marques <joseph@redhat.com>
Date:   Wed Jun 16 00:54:05 2010 -0400

    BZ-594516: support implicit substring matching for bracketed properties


On the one hand, this can be viewed as a feature enhancement because the query generator is doing precisely what it was coded to do.  On the other hand, it can be viewed as a regression because the user-perceived functionality/interaction has changed.

Recall that the SOA plugin didn't exist when the DynaGroup functionality was originally written.  Historically, all JBossAS servers (JBossAS community editions as well as EAP servers) could be grouped by cluster membership with with a single expression:

"groupby resource.trait[partitionName]"

But the SOA server chose a different name for this internal attribute / trait.  Instead of using 'partitionName' it uses 'MCBean|ServerConfig|*|partitionName'.  So this fix makes it possible to use the single expression above to group JBossAS, EAP, and SOA servers.

FYI: this was literally a two-line fix.  The probably of regression is extremely low due to having a full set of unit tests in place to verify that the ExpressionEvaluator is generating the correct JPQL.  This enhancement is specifically verified through the half dozen unit tests that generate JPQL for bracketed expressions.


Keep in mind, we still need to fix https://bugzilla.redhat.com/show_bug.cgi?id=594520 , which is a clear regression over previous releases.

Comment 6 Corey Welton 2010-06-28 17:01:17 UTC
QA Verified.  Creating dynagroups via this query results in the dynagroup being appropriately populated.

Comment 7 Corey Welton 2010-08-12 16:46:15 UTC
Mass-closure of verified bugs against JON.

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