How can I resolve proxy class name mismatches that break Spring Security ACL @PostFilter?

Question

I'm slowly updating a very old project of mine to modern versions of libraries. Earlier I have reached the following versions:

• Spring 6.0.13
  • spring-context
  • spring-context-support
  • spring-orm
  • spring-webmvc
• Spring Security 6.1.4
• Hibernate 6.2.13.Final

I don't use/haven't migrated yet to Spring boot, or Spring data.

I started updating to latest, and I’m facing an issue where Hibernate’s ByteBuddy-generated proxy classes are not recognized in my ACL lookup, so my @PostFilter fails—ACL tables store the original class names, but runtime proxies don’t match. (See https://github.com/spring-projects/spring-framework/issues/21111 for context.)

Currently I don't understand why this issue isn’t more widely reported. Are most users not using the same ACL model or @PostFilter (or relying on Spring Data JPA's built-in support), or is there another preferred workaround?

Currently, I’m using the workaround from: https://github.com/spring-projects/spring-framework/issues/21111#issuecomment-453468521 I've copied and patched Spring Security’s ObjectIdentityImpl into my codebase (keeping the original package) so that the proxy detection logic works correctly. However, that isn’t an ideal solution long term since I’d have to update my patch with every Spring Security release. Also, I get build warning:

[WARNING] org.springframework.security.acls.domain.ObjectIdentityImpl scanned from multiple locations: 
file:///…/target/classes/org/springframework/security/acls/domain/ObjectIdentityImpl.class, 
jar:file:///…/spring-security-acl-6.4.2.jar!/org/springframework/security/acls/domain/ObjectIdentityImpl.class

I'm exploring several alternatives:

Switching to using Spring Data: I’ve heard this might bypass some of these issues, but I’m unclear if it fully resolves the mismatch or if the ACL model itself is impacted. My domain object level acl config is very old style based on: http://krams915.blogspot.fr/2011/01/spring-security-3-full-acl-tutorial.html

Using a workaround in my code, do things differently avoiding the problem How?

Forking Spring Security ACL: Create and use a patched Maven artifact (e.g. version 6.4.2-patched1) that fixes the proxy detection.

Custom proxy detection strategy: Implement a custom ObjectIdentityRetrievalStrategy (or similar) that unproxies classes, attach it to AclPermissionEvaluator and AclPermissionCacheOptimizer, ensuring the correct user class is always used. However, I’m not sure if this approach will unproxy other cases, which might fire database requests bypassing the usefulness of proxy in the first place.

Manual unproxying in DAOs: Integrate unproxying logic in my data access layer, but that seems messy and error-prone.

My question is: What is the most robust, maintainable approach to resolve the proxy class name mismatch so that ACL lookups (and thus @PostFilter) work correctly?

Any insights or alternative strategies to handle proxy unwrapping in this context would be appreciated!