[ https://issues.apache.org/jira/browse/JCR-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874514#comment-16874514 ]
Ate Douma commented on JCR-4455: -------------------------------- As we want to proceed with the upgrade to 2.18.2 anyhow, for the time being I'll patch our own version of jackrabbit by reverting the changes of JCR-4339, combined with the suggested simple one-line workaround from Giacomo in that issue, until this new bug is addressed and back ported again. > 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 > Affects Versions: 2.18.2 > Reporter: Ate Douma > Priority: Major > Attachments: exposing-JCR-4455.patch > > > [~c_koell] > When reviewing 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 trying to use > multiple index-rule definitions for one node type. > The logic for finding the applicable indexing rule for a specific property no > longer considers (checks) if the there is a condition for that property. > Instead, that check is postponed/moved to the method *calling* > #getApplicableIndexingRule. > But this is incorrect because now the #getApplicableIndexingRule method > returns the first *type* matching rule, regardless of the *property* it > 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 enhanced > version of test resource indexing_config6.xml, which can be used to verify > the logic now is broken: > {code:xml} > <index-rule nodeType="nt:unstructured"> > <property>other</property> > </index-rule> > <index-rule nodeType="nt:unstructured" condition="@foo = 'high'"> > <property>foo</property> > </index-rule>{code} > The important points to expose the new bug is: > * the index-rule for property other is defined *before* the index-rule for > property foo > * (for this example) the index-rule for property other doesn't have a > condition > With the above, the property foo will *not* be indexed, regardless its value, > because the first 'matching' rule returned from #getApplicableIndexingRule > 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 > rule.isIndexed(propertyName: foo), because *that* rule doesn't has a > propertyConfig for foo (only for other). > I'll attach a patch (based on trunk) to demonstrate the above failing using > the new IndexingConfigurationImplTest#testMatchCondition test. > Note that the current #testMatchCondition() test itself also is broken: it > 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} > <index-rule nodeType="nt:unstructured" condition="@foo = 'high'"> > </index-rule>{code} > it actually should be: > {code:xml} > <index-rule nodeType="nt:unstructured" condition="@foo = 'high'"> > <property>foo</property> > </index-rule>{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 (v7.6.3#76005)