fix: identify classes with an Integer ID field [DHIS2-16092]

[netroms]

Summary

• Issue reported that sometimes there is a WARN in the log complaining about wrong identifiers being sent to the Hibernate Redis cache invalidation when the identifier is an Integer instead of a Long.
• Added type check on the class id field and cast/parse to Integer if field is an Integer.
• To avoid excessive superclass discovery mechanisms to infer correct class for the ID field, a best effort to check for an Integer ID field on just the incoming class is done, since classes with an Integer ID field does not extend any superclasses.

Manual test for bug/issue

1. Start servers with a Redis server instance running already, use following dhis.conf lines to activate Redis cache invalidation:

redis.host = localhost
redis.port = 6379
redis.cache.invalidation.enabled = on 

2. Start at least two DHIS2 instances with the config above.
3. Log in to a server and go to the message inbox, like: https://play.dhis2.org/dev/dhis-web-messaging
4. Compose a new "Feedback message" use any subject and body.
5. When pressing send, observe a WARN in the log looking like this:

WARN 2023-10-20T15:32:00,166 Fetching new entity failed, failed to execute get query! entityId=86556, entityClass=class org.hisp.dhis.message.UserMessage (BaseCacheEvictionService.java [lettuce-epollEventLoop-7-2])
org.hibernate.TypeMismatchException: Provided id of the wrong type for class org.hisp.dhis.message.UserMessage. Expected: class java.lang.Integer, got class java.lang.Long
at org.hibernate.event.internal.DefaultLoadEventListener.checkIdClass(DefaultLoadEventListener.java:155) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
at

Automatic tests

N/A

Jira

DHIS2-16092

[codecov]

Codecov Report

Merging #15554 (aead875) into master (052af53) will increase coverage by 16.73%.
The diff coverage is 16.66%.

@@              Coverage Diff              @@
##             master   #15554       +/-   ##
=============================================
+ Coverage     49.45%   66.19%   +16.73%     
- Complexity    23282    31225     +7943     
=============================================
  Files          3485     3485               
  Lines        129758   129762        +4     
  Branches      15141    15141               
=============================================
+ Hits          64174    85895    +21721     
+ Misses        59514    36777    -22737     
- Partials       6070     7090     +1020     

Flag	Coverage Δ
integration	49.77% <0.00%> (?)
integration-h2	32.35% <0.00%> (-0.02%)	⬇️
unit	30.34% <16.66%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...einvalidation/redis/CacheInvalidationListener.java	38.77% <16.66%> (-0.59%)	⬇️

... and 1223 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 052af53...aead875. Read the comment docs.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[david-mackessy]

It looks like if there is no id field and the NoSuchFieldException is thrown that we still try parse the idPart as a long even though there is no id field. Is that what we want to try here?
Some tests for this logic would be beneficial I think, with so many conditional branches in this method.

[netroms]

My thinking here is that if there is an ID field on the class it will be an Integer. If you do a search for "int id;" you will see the result is only classes that has the ID field on the actual class and don't inherit it from the superclass. So when it's not an int field, it will be a Long, mostly via the BaseIdentifiableObject. Making logic to catch every single case here is not the intention.