Support for JPA 4.0 EntityAgent

[jhoeller]

Following up on basic JPA 4.0 runtime compatibility in #35705, we can add transactional support for EntityAgent management, similar to the existing support for Hibernate's StatelessSession in #7184.

The SmartFactoryBean#getObject(Class) mechanism can be used for dependency injection, along the lines of LocalSessionFactoryBean but following @PersistenceContext-style semantics for the EntityAgent proxy: delegating to a transactional EntityAgent if a transaction is active, performing a non-transactional operation otherwise.

The following additions are to be expected:

• SharedEntityAgentCreator next to SharedEntityManagerCreator (possibly sharing a common InvocationHandler implementation, in particular a common DeferredQueryInvocationHandler). While this will require building against the JPA 4.0 API, that class is standalone and does not break JPA 3.2 compatibility.
• AbstractEntityManagerFactoryBean#getObject(Class) supporting a shared EntityAgent instance next to its shared EntityManager. This will require reflective loading of the EntityAgent type without a hard reference to it, plus conditional initialization of an untyped sharedEntityAgent field via SharedEntityAgentCreator that can then be returned from getObject(Class) if the requested type is assignable to the reflectively loaded EntityAgent Class.

[AtharvUrunkar]

Hi @jhoeller,
I’d like to work on this.

I plan to follow the existing SharedEntityManagerCreator and the Hibernate StatelessSession support patterns, introduce a reflection-safe SharedEntityAgentCreator, and extend AbstractEntityManagerFactoryBean#getObject(Class) accordingly.

The implementation will avoid hard dependencies on JPA 4.0 to preserve JPA 3.2 compatibility, and I’ll add test coverage for both transactional and non-transactional scenarios.

Please let me know if this approach aligns with the intended direction before I proceed further. Thanks!

[jhoeller]

@AtharvUrunkar thanks for volunteering! That said, please note that I primarily created this issue for myself, not for community contributions. It is an early analysis of what we can accomplish for our 7.1 without breaking JPA 3.2 compatibility at runtime - but it is not actionable right now since it needs a JPA 4.0 API milestone to be published and then #35705 sorted out first. For testing and for integration into our 7.1 build, we need EclipseLink 6.0 and Hibernate 8.0 pre-release versions which are half a year away still.

[AtharvUrunkar]

Thanks for the clarification, @jhoeller — that makes sense.

I understand this is exploratory at this stage and dependent on a published JPA 4.0 API milestone as well as the follow-up on #35705, plus provider availability. I’ll hold off for now and keep an eye on the prerequisites as they evolve.

Happy to revisit or help later once this becomes actionable. Thanks for sharing the early analysis.