Following up on #33750 and #33414, there is a remaining problem with the PersistenceUnitInfo#getTransactionType() in JPA 3.2 where the jakarta.persistence.spi.PersistenceUnitTransactionType enum is deprecated for removal - and the latest state of JPA 4.0 already has it replaced with jakarta.persistence.PersistenceUnitTransactionType. Anticipating that binary-incompatible breakage in the JPA SPI and taking into account that the new jakarta.persistence.PersistenceUnitTransactionType enum is available in JPA 3.2 (just not used in the JPA SPI yet), we can revise our PersistenceUnitInfo management toward decoupling it from the JPA PersistenceUnitInfo interface itself:
- Internally in
DefaultPersistenceUnitManager, we hang on to SpringPersistenceUnitInfo which does not implement PersistenceUnitInfo directly anymore, then turning into an actual JPA PersistenceUnitInfo proxy (automatically adapting to JPA 3.2 vs 4.0) when requested from the PersistenceUnitManager.
MutablePersistenceUnitInfo as exposed to PersistenceUnitPostProcessor provides the same common accessors and mutators as before. It just does not directly implement PersistenceUnitInfo anymore (aligned with SpringPersistenceUnitInfo which it serves as a base class for), so it cannot be passed into PersistenceUnitInfo-accepting methods anymore (which was never an intended scenario there anyway).
MutablePersistenceUnitInfo consistently exposes the non-deprecated jakarta.persistence.PersistenceUnitTransactionType in its set/getTransactionType methods now, which prevents awkward "deprecated for removal" warnings on JPA 3.2 for anyone calling those methods.
- As a desirable side effect, persistence unit mutation only works during the bootstrap phase now.
PersistenceUnitInfo handles obtained via EntityManagerFactoryInfo at runtime can only be downcast to SmartPersistenceUnitInfo but not to MutablePersistenceUnitInfo anymore, preventing late mutation that would not get picked up by the persistence provider.
- As a side note, it is not entirely new to receive a
PersistenceUnitInfo proxy from Spring: We had this before for JPA 1.0 vs 2.0 side-by-side support where a proxy was returned in case of JPA 2.0 (also preventing runtime downcasts to MutablePersistenceUnitInfo back then).
Following up on #33750 and #33414, there is a remaining problem with the
PersistenceUnitInfo#getTransactionType()in JPA 3.2 where thejakarta.persistence.spi.PersistenceUnitTransactionTypeenum is deprecated for removal - and the latest state of JPA 4.0 already has it replaced withjakarta.persistence.PersistenceUnitTransactionType. Anticipating that binary-incompatible breakage in the JPA SPI and taking into account that the newjakarta.persistence.PersistenceUnitTransactionTypeenum is available in JPA 3.2 (just not used in the JPA SPI yet), we can revise ourPersistenceUnitInfomanagement toward decoupling it from the JPAPersistenceUnitInfointerface itself:DefaultPersistenceUnitManager, we hang on toSpringPersistenceUnitInfowhich does not implementPersistenceUnitInfodirectly anymore, then turning into an actual JPAPersistenceUnitInfoproxy (automatically adapting to JPA 3.2 vs 4.0) when requested from thePersistenceUnitManager.MutablePersistenceUnitInfoas exposed toPersistenceUnitPostProcessorprovides the same common accessors and mutators as before. It just does not directly implementPersistenceUnitInfoanymore (aligned withSpringPersistenceUnitInfowhich it serves as a base class for), so it cannot be passed intoPersistenceUnitInfo-accepting methods anymore (which was never an intended scenario there anyway).MutablePersistenceUnitInfoconsistently exposes the non-deprecatedjakarta.persistence.PersistenceUnitTransactionTypein itsset/getTransactionTypemethods now, which prevents awkward "deprecated for removal" warnings on JPA 3.2 for anyone calling those methods.PersistenceUnitInfohandles obtained viaEntityManagerFactoryInfoat runtime can only be downcast toSmartPersistenceUnitInfobut not toMutablePersistenceUnitInfoanymore, preventing late mutation that would not get picked up by the persistence provider.PersistenceUnitInfoproxy from Spring: We had this before for JPA 1.0 vs 2.0 side-by-side support where a proxy was returned in case of JPA 2.0 (also preventing runtime downcasts toMutablePersistenceUnitInfoback then).