HSEARCH-3388 Search 6 groundwork - Output the full property key (as provided by the user) in case of parsing error

[yrodiere]

https://hibernate.atlassian.net//browse/HSEARCH-3388

[sonarcloud]

SonarQube analysis found issues:
Bugs: 0
Vulnerabilities: 0
Code Smells: 2

See all issues in SonarCloud

[coveralls]

Pull Request Test Coverage Report for Build 2

• 70 of 83 (84.34%) changed or added relevant lines in 16 files are covered.
• 2 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.07%) to 86.625%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
engine/src/main/java/org/hibernate/search/engine/cfg/impl/FallbackConfigurationPropertySource.java	0	1	0.0%
engine/src/main/java/org/hibernate/search/engine/cfg/impl/PropertiesConfigurationPropertySource.java	0	1	0.0%
engine/src/main/java/org/hibernate/search/engine/cfg/impl/FunctionConfigurationProperty.java	8	10	80.0%
engine/src/main/java/org/hibernate/search/engine/cfg/impl/PrefixedConfigurationPropertySource.java	0	3	0.0%
engine/src/main/java/org/hibernate/search/engine/cfg/impl/OverriddenConfigurationPropertySource.java	9	15	60.0%

Files with Coverage Reduction	New Missed Lines	%
engine/src/main/java/org/hibernate/search/engine/cfg/impl/FallbackConfigurationPropertySource.java	1	46.67%
engine/src/main/java/org/hibernate/search/engine/cfg/impl/MaskedConfigurationPropertySource.java	1	53.33%

Totals
Change from base Build 46:	-0.07%
Covered Lines:	11347
Relevant Lines:	13099

---

💛 - Coveralls

[sonarcloud]

SonarQube analysis found issues:
Bugs: 0
Vulnerabilities: 0
Code Smells: 1

See all issues in SonarCloud

[gsmet]

Can't say I'm excited by this one. Wouldn't it be better to keep the original property handy so that we don't have to resolve it back?

[yrodiere]

Wouldn't it be better to keep the original property handy so that we don't have to resolve it back?

Not sure what you're suggesting, but one problem is that we don't know the full property key where we use it, we only know the radical. So we can't really display the full property key without some additional code to resolve it.

For example in the ORM integration we use the hibernate.search. prefix, but in Infinispan I know for a fact that they currently (with Search 5) prepend the prefix in their integration, and users don't use it when configuring (or they use another prefix, I'm not sure). So if you consider the property defining the backend to use for "myIndex", the full key will be "hibernate.search.index.myIndex.backend" in the ORM integration, but it will be something like "index.myIndex.backend" in Infinispan. Or maybe it will be even more different, because Infinispan is configured per-cache and has only one index per cache; but in any case, this PR will allow their configuration property source to resolve the key to a string that makes sense for end users.

Out of curiosity, what is your main concern? Maybe I can do something about it.

[gsmet]

Out of curiosity, what is your main concern? Maybe I can do something about it.

Well, it's just that it feels weird to have the property to begin with, then lose some information about it, and then resolve it back to what it was.

But I suppose it's how it is.

Merging.

[gsmet]

Merged!