[DROOLS-6892] Wrapper class unwrapped value is not indexed in exec-model

[tkobayas]

Ports
This PR is for 7.x
for main -> https://github.com/kiegroup/drools/pull/4328

JIRA:
https://issues.redhat.com/browse/DROOLS-6892

How to replicate CI configuration locally?

Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.

build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

How to retest this PR or trigger a specific build:

• a pull request please add comment: Jenkins retest this

• for a full downstream build

  • for jenkins job: please add comment: Jenkins run fdb
  • for github actions job: add the label run_fdb

• a compile downstream build please add comment: Jenkins run cdb

• a full production downstream build please add comment: Jenkins execute product fdb

• an upstream build please add comment: Jenkins run upstream

[tkobayas]

Jenkins run fdb

[tkobayas]

Jenkins run fdb

[tkobayas]

non-exec-model

• property reactivity
  • Mask: AlphaNode.declaredMask relies on ClassUtils.getAccessibleProperties()
  • React: AsmUtil.parseModifiedProperties() -> modificationMask relies on ClassUtils.getAccessibleProperties()
• index
  • Props and index are stored by ClassFieldAccessorFactory.getClassFieldReader() -> ClassFieldInspectorImpl.processClassWithoutByteCode()

exec-model

• property reactivity
  • Mask: AlphaNode.declaredMask relies on ClassUtils.getAccessibleProperties()
  • React: Writing D.reactOn("prop-name") relies on ClassUtils.getAccessibleProperties(). Also the prop react mask BitMaskUtil.calculatePatternMask() relies on DomainClassMetadata.getPropertyIndex()
• index
  • D.alphaIndexedBy(..., ..., xxx_Metadata_INSTANCE.getPropertyIndex("prop-name"), ...) relies on DomainClassMetadata.getPropertyIndex()

As you see, in Non-exec-model, props for property reactivity and props for index are separately managed.

On the other hand, in exec-model, property reactivity relies on ClassUtils.getAccessibleProperties() and also index relies on DomainClassMetadata.getPropertyIndex() which is populated by ClassUtils.getAccessibleProperties().

One possible approach is to enhance ClassUtils.getAccessibleProperties() to include non-getter method (e.g. Person.calcAge(), Integer.intvalue()). However, it will have a wide impact to property reactivity behaviour on both non-exec-model and exec-model.

In this PR, I took a conservative approach only focusing on the index issue. I don't change ClassUtils.getAccessibleProperties() so property reactivity wouldn't change. For exec-model DomainClassMetadata.getPropertyIndex(), I call getAccessiblePropertiesIncludingNonGetterValueMethod which returns both accessibleProperties and nonGetterValueMethods. In exec-model, D.reactOn still refers to DomainClassMetadata.getPropertyIndex() but the index number is consistent with ClassUtils.getAccessibleProperties() because nonGetterValueMethods are added at last. So now Person.calcAge() and Integer.intvalue() can be indexed. But they are not subject to property reactivity. If we want to improve property reactivity to react to Person.calcAge(), I may raise a new JIRA (note: we don't want to react to Integer.intvalue() which is immutable).

@mariofusco Feel free to share your thought on this. Thanks!

[mariofusco]

I guess this was for debug (you can use peek instead of map in future) and now you can remove it.

[tkobayas]

Thank you for spotting! Fixed.

[mariofusco]

Ok for me, I just left a minor comment. I just wonder if this could have any relevant impact on executable model generation time. I think we could merge it anyway, but maybe you could ask Daniel to run some of our benchmarks against it?

[tkobayas]

FDB : flaky test

org.kie.server.router.repository.FileRepositoryTest.testWatchServiceOnLatelyCreatedConfigFile
java.lang.AssertionError: expected:<2> but was:<0>

[tkobayas]

I just wonder if this could have any relevant impact on executable model generation time. I think we could merge it anyway, but maybe you could ask Daniel to run some of our benchmarks against it?

Yes, it would potentially have a negative impact on executable model generation time. I'll check with Daniel. Thank you for the suggestion.

@hellowdan I sent an email to you. Thanks!