From dev-return-50820-archive-asf-public=cust-asf.ponee.io@jackrabbit.apache.org Wed Sep 4 15:54:06 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 58D82180674 for ; Wed, 4 Sep 2019 17:54:06 +0200 (CEST) Received: (qmail 84599 invoked by uid 500); 4 Sep 2019 21:17:51 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 84521 invoked by uid 99); 4 Sep 2019 21:17:51 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Sep 2019 21:17:51 +0000 Received: from jira-he-de.apache.org (static.172.67.40.188.clients.your-server.de [188.40.67.172]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 045A6E30F4 for ; Wed, 4 Sep 2019 15:54:04 +0000 (UTC) Received: from jira-he-de.apache.org (localhost.localdomain [127.0.0.1]) by jira-he-de.apache.org (ASF Mail Server at jira-he-de.apache.org) with ESMTP id 7390B7822CC for ; Wed, 4 Sep 2019 15:54:00 +0000 (UTC) Date: Wed, 4 Sep 2019 15:54:00 +0000 (UTC) From: "Julian Reschke (Jira)" To: dev@jackrabbit.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (JCR-4455) condition index-rule handling more broken after JCR-4339 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/JCR-4455?page=3Dcom.atlassian.= jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4455: -------------------------------- Labels: candidate_jcr_2_12 (was: candidate_jcr_2_14) > condition index-rule handling more broken after JCR-4339 > -------------------------------------------------------- > > Key: JCR-4455 > URL: https://issues.apache.org/jira/browse/JCR-4455 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: core > Affects Versions: 2.18.2 > Reporter: Ate Douma > Assignee: Claus K=C3=B6ll > Priority: Major > Labels: candidate_jcr_2_12 > Fix For: 2.20, 2.16.5, 2.19.4, 2.18.3, 2.14.8 > > Attachments: JCR-4455.patch, exposing-JCR-4455.patch > > > [~c_koell] > When=C2=A0reviewing the fix applied for JCR-4339 before going through an = upgrade to 2.18.2, I noticed that, while it fixes the reported problem, it = does so only in simple ('happy path') scenarios. Now it is broken when tryi= ng to use multiple index-rule definitions for one node type. > The logic for finding the applicable indexing rule for a specific propert= y no longer considers (checks) if the there is a condition for that propert= y. Instead, that check is postponed/moved to the method *calling*=C2=A0#get= ApplicableIndexingRule. > But this is incorrect because now the #getApplicableIndexingRule method = returns the first *type*=C2=A0matching rule, regardless of the *property*= =C2=A0it should be applicable for. > For example, it is perfectly feasible, and sometimes even needed, to have= multiple index-rules for the same node type, like the following=C2=A0enhan= ced version of test resource indexing_config6.xml, which can be used to ver= ify the logic now is broken: > {code:xml} > > other > > > foo > {code} > =C2=A0The important points to expose the new bug is: > * the index-rule for property other is defined *before* the index-rule f= or property foo > * (for this example) the index-rule for property other doesn't have a co= ndition > With the above, the property foo will *not* be indexed, regardless its va= lue, because the first 'matching' rule returned from #getApplicableIndexing= Rule for a node of type nt:unstructured will be the rule for property other= . But will always return false on the (now postponed/delegated) call to rul= e.isIndexed(propertyName: foo), because *that* rule doesn't has a propertyC= onfig for foo (only for other). > I'll attach a patch (based on trunk) to demonstrate the above failing usi= ng the new IndexingConfigurationImplTest#testMatchCondition test. > Note that the current #testMatchCondition() test itself also is broken: i= t actually *does not* test the intended condition, but tests for it to *not= * match using assertFalse instead of assertTrue. > Which indeed is needed to pass the test because the indexing_config6.xml= configuration file itself contains an invalid (incomplete) index-rule. > Instead of the current content: > {code:xml} > > {code} > it actually should be:=C2=A0 > {code:xml} > > foo > {code} > to pass the test with assertTrue. > I'll also fix that test method in my patch, which then however will fail,= because of the above reported problem. -- This message was sent by Atlassian Jira (v8.3.2#803003)