Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 594516 - search: group definitions parameterized filters are too strict
search: group definitions parameterized filters are too strict
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
3.0.0
All Linux
high Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
Corey Welton
:
Depends On:
Blocks: jon-sprint11-bugs
  Show dependency treegraph
 
Reported: 2010-05-20 17:46 EDT by Joseph Marques
Modified: 2010-08-12 12:46 EDT (History)
2 users (show)

See Also:
Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-12 12:46:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joseph Marques 2010-05-20 17:46:58 EDT
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 17:56:05 EDT
(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 17:57:50 EDT
Ignore that needinfo flag
Comment 3 Udaypal Aarkoti 2010-06-15 21:53:39 EDT
Just want to clarify my comment earlier. Since the
Comment 4 Udaypal Aarkoti 2010-06-15 21:54:48 EDT
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 01:36:12 EDT
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 13:01:17 EDT
QA Verified.  Creating dynagroups via this query results in the dynagroup being appropriately populated.
Comment 7 Corey Welton 2010-08-12 12:46:15 EDT
Mass-closure of verified bugs against JON.

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