Spring-boot: Let Hibernate configure the transaction manager on WebSphere

[hlreb]

When using Spring Boot 1.5.2 in Websphere 8.5.5.10, Sping Data Jpa autoconfiguration (i.e. class HibernateJpaAutoConfiguration) detects the WebSphere container and attempts to configure "JtaPlatformManager" using one of the following classes : org.hibernate.engine.transaction.jta.platform.internal.WebSphereExtendedJtaPlatform and org.hibernate.service.jta.platform.internal.WebSphereExtendedJtaPlatform.

The latter is no longer existing in Hibernate 5 (seems to be cleaned out), so there is not point in referring to it in Spring Boot autoconfiguration. The former seems to be an incomplete implementation (many methods raise UnsupportedOperationException).
So when a transaction is rolled back, e.g. because of a bean validation constraint violation, an UnsupportedOperationException is raised instead of ConstraintViolationException.

A workaround is to replace the WebSphereExtendedJtaPlatform with org.hibernate.service.jta.platform.internal.WebSphereJtaPlatform, by the means of custom JPA properties (spring.jpa.properties.*) but I am not sure if it has side effects

[philwebb]

It looks like org.hibernate.service.jta.platform.internal.WebSphereExtendedJtaPlatform was dropped in Hibernate 4.3.

[philwebb]

See #2326

[philwebb]

Looks like you need to jump though quite a few hoops to use later versions of Hibernate with Websphere 8.5.5.

I'm not sure if we we should change our existing logic which at least allows JPA 2.0 to be used without issue. @wilkinsona probably has some thoughts on this.

[hlreb]

I am afraid JPA 2.0 is currently _not_ working correctly in WebSphere 8.5.5 using Spring Boot autoconfiguration. When JPA2.0 detects a javax.validation error, a ConstraintViolationException should be raised, e.g.

Validation failed for classes [com.example.app.MyClass] during persist time for groups [javax.validation.groups.Default, ]nList of constraint violations:[ntConstraintViolationImpl{interpolatedMessage='must be at least equal to 1000', propertyPath=theAttribute, rootBeanClass=class com.example.app.ABeanClass, messageTemplate='{javax.validation.constraints.Min.message}'}

but in the case of WebSphere, all we get is java.lang.UnsupportedOperationException.

I understand we might come across other issues when we use features of JPA2.1 (that are not part of JPA2.0) but we are not there yet.

[snicoll]

Brainstorming with @jhoeller on this. We should probably invert the lookup order. And remove the internal one on master since we won't support 4.3 anymore.

[aguibert]

Hi, WebSphere/Liberty developer here. We contributed a new WebSphereLibertyJtaPlatform platform to Hibernate which is picked up as of version 5.2.13 and 5.3.Beta2. This new platform class allows Hibernate to fully integrate with the WebSphere transaction manager and does not throw any UOEs.

Unless Spring is explicitly setting the hibernate.transaction.jta.platform property, Hibernate is now capable of auto-detecting availability of the WebSphere transaction manager and using WebSphereLibertyJtaPlatform out of the box.

Further details here: https://hibernate.atlassian.net/browse/HHH-11571

[snicoll]

@aguibert thank you very much. Is https://github.com/snicoll/spring-boot/commit/b38187ad9e3e6eef73c0f9b4f70e4a3c1d56da80 what you had in mind before I start digging a bit more?

[aguibert]

What you have seems reasonable @snicoll, but I don't understand why Spring still calls configureSpringJtaPlatform() for non-WebSphere platforms? All of the big app servers (WebSphere, JBoss, Wildfly, Weblogic, etc) have their own JtaPlatform impls in Hibernate nowadays, see: https://github.com/hibernate/hibernate-orm/tree/master/hibernate-core/src/main/java/org/hibernate/engine/transaction/jta/platform/internal

[snicoll]

Good point @aguibert! I've spent more time digging and I agree about your analysis. I've created #14194 that supersedes this issue. Thanks again!

[snicoll]

After further investigation, I am changing my mind (see the analysis in #14194) and I'll fix things only for the Websphere case for now.