Develop Reference

Hibernate validator and spring versions compatibility

We are using hibernate validator version 5.2.5.Final with spring version 5.0.15RELEASE to validate the input data along with bean-io framework.
Now we are planning to upgrade the hibernate validator to latest version 6.1.5 to improve the performance of the workflow.
Kindly provide the compatible version of spring framework version with latest hibernate validator.

The following part of the documentation will give you a hint.
As of Spring 5.0, this class requires Bean Validation 1.1+, with special support for Hibernate Validator 5.x (see setValidationMessageSource(org.springframework.context.MessageSource)). This class is also runtime-compatible with Bean Validation 2.0 and Hibernate Validator 6.0, with one special note: If you'd like to call BV 2.0's getClockProvider() method, obtain the native ValidatorFactory through #unwrap(ValidatorFactory.class) and call the getClockProvider() method on the returned native reference there.

Override JPA of IBM WAS

I am using JPA 2.1 in my project (Hibernate 5.x) and deploying in IBM WAS 8.5.5.
Since IBM WAS 8.5.5 supports only JPA 2.0 by the container, There is persistence loader issue during application deployment.
Is it possible to configure custom JPA at app level in WAS.
I already tried - IBM WAS Documentation

You said you tried https://developer.ibm.com/wasdev/docs/can-i-use-jpa-2-1-on-websphere-application-server/, but what part of this document is not working? This is the page I would reference if you are trying to get JPA 2.1 running on 8.5.5.
Some alternate suggestions:
Traditional WebSphere v9 supports the JPA 2.1 specification level. I would recommend using WebSphere v9 for your project instead of 8.5.5 if you really need to use Hibernate 5.x
Hibernate 4.2 was the last version that supports JPA 2.0. You can downgrade to this version of Hibernate if you dont have to use JPA 2.1
Either of these solutions gain you container support and will provide the JPA API bundle for you. Whichever you go with, make sure not to bundle your Hibernate JPA persistence API bundles in your application. Hibernate repackages its API into "hibernate-jpa-2.x-api.Final.jar". I have seen this before as a conflict that customers build into their applications.

With class loading strategy, I was able to override the JPA 2.0 of container.
using the inputs from IBM Developers support.

using JPA 2.0 on hibernate 5 when deploy to websphere

when I try to deploy my application on Websphere Application Server 9.0 I got this error
An error occurred in the org.hibernate.jpa.HibernatePersistenceProvider persistence provider when it attempted to create the container entity manager factory for the ApplicationEntityManager persistence unit. The following error occurred: java.lang.ClassCastException: org.hibernate.jpa.HibernatePersistenceProvider incompatible with javax.persistence.spi.PersistenceProvider
and someone suggests me to downgrade my JPA to 2.0. is this possible to use JPA 2.0 with Hibernate 5.2.1. or there is another solution to solve my problem.

If using WebSphere Application Server traditional,
here are the instructions to set the JPA spec level provided by the server,
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_9.0.0/com.ibm.websphere.base.doc/ae/tejb_idmod_jpaspec.html
That said, Hibernate 5.2.1 appears to have a dependency on JPA 2.1, not 2.0. See the dependencies indicated here,
https://mvnrepository.com/artifact/org.hibernate/hibernate-core/5.2.1.Final
The issue might be caused by including a copy of the JPA spec JARs within the application such that the server and the application are trying to load different copies of the same class which collide and produce this error. Check your application and remove all copies of the JPA spec JAR from it (including any supplied by Hibernate), such that the server copy alone is always used to load JPA.

Is it possible to configure JBoss EAP 6.4.x for Spring 4 and Hibernate 4.3.10 using JPA 2.1 by configuring it over jboss-deployment-structure.xml?

We recently switched to Java 8 to use java.time API (LocalDate, LocalDateTime,...). Therefore we updated our Hibernate dependency to version 4.3.10. We wrote some AttributeConverters to help Hibernate to map new Java 8 classes to the database.
e.g.
#Converter(autoApply = true)
public class LocalDateConverter implements AttributeConverter<LocalDate, Date>
To use javax.persistence.Converter and javax.persistence.AttributeConverter we had to update Hibernate to 4.3.10 to work with JPA 2.1. But JBoss EAP 6.4.x does not support JPA 2.1 and comes along with JPA 2.0. Therefore, we get some deployment errors. How can we get our JPA 2.1 application running on JBoss!?
Should we downgrade Hibernate to a Hibernate version lower than 4.3.10 to work with JPA 2.0?
Or is there a nice way to exclude JPA 2.0 using the jboss-deployment-structure.xml?

You are mixing up Java8/JDK8 with JEE7 specification. JBoss EAP 6.4 is a JEE6 container. JEE6 requires JPA 2.0 which is why you have JPA 2.0 implementation in JBoss EAP 6.4. Once JBoss releases a JEE7 implemented container, you should be able to use JPA 2.1 there.
It should be fine to use JBoss EAP 6.4 running on JDK8.
I would not recommend modifying the hibernate jars or manually including JPA 2.1 jars. There are other aspects of JPA for example the secondary cache which is implemented by Infinispan in JBoss might not have been tested with JPA 2.1 cache stores.
If you really need to utilize a JEE7 JBoss container, then take a look at WilFLy 9. However, this is a community build, so it is not supported.

Should you default to the JPA provider of the application server?

I have a 100% JPA2 compliant application which needs to be portable to many application servers. Being JPA compliant (theoretically) means we can switch JPA providers via configuration (e.g. without changing source code) -- (right???).
When running within a servlet container (e.g. Tomcat, Jetty) the application is configured to run with Hibernate. We choose Hibernate over TopLink and Eclipselink for its maturity and performance. So far this works.
However, when running within a Java EE application server, should we default to the JPA provider therein, or stick with Hibernate?
I know within JBoss, the provider is Hibernate so it probably doesn't matter. However, I think the provider within WebLogic is Eclipselink. I have no idea what the provider WebSphere or Glassfish use, but I have seen detailed instructions on how to use Hibernate as the provider within those application servers.
I guess another way to ask the question is what would we be missing by using Hibernate in these application servers?

I have a 100% JPA2 compliant application which needs to be portable to many application servers. Being JPA compliant (...) means we can switch JPA providers via configuration (...)
Yes.
(...) However, when running within a Java EE application server, should we default to the JPA provider therein, or stick with Hibernate?
Well, if you deploy on a Java EE 6 server, this doesn't really matter. It's not clear who is going to run the application and you can maybe make recommendations but the runtime is actually "not your business" :) Also note that you may not benefit from support if you don't use the default provider (if this matters).
I know within JBoss, the provider is Hibernate so it probably doesn't matter. However, I think the provider within WebLogic is Eclipselink. I have no idea what the provider WebSphere or Glassfish use, but I have seen detailed instructions on how to use Hibernate as the provider within those application servers.
First of all, keep in mind that JPA 2.0 is part of Java EE 6 and that GlassFish v3 is the only one Java EE 6 container at this time. WebLogic and WebSphere are Java EE 5 server, they may not support JPA 2.0.
Now, regarding the default providers:
GlassFish v3 uses EclipseLink 2.0 as default provider but can be configured to use Hibernate 3.5 (through an add-on).
In Weblogic 10.3.2, the default JPA provider is OpenJPA/Kodo and EclipseLink 1.2 is available as a WLS module. In WLS 10.3.3 (not released yet), EclipseLink 2.0 will be available as a WLS module, the default being still OpenJPA/Kodo. But, the container JPA API will still be JPA 1.0! It seems possible to package a JPA 2.0 provider inside your application. See this thread and this page. But this is not officially supported and doing this same thing with Hibernate 3.5 might be another story.
In WebSphere 6 and 7, the default provider is OpenJPA. This link will give you some details about the way to change the default provider (and the consequences). But I can't tell you more.
I guess another way to ask the question is what would we be missing by using Hibernate in these application servers?
As I mentioned, this may not be supported by the vendor. Additionally, if you want to maximize portability and plan to deploy your application in a near future, going for JPA 2.0 is maybe not a wise choice (or too optimistic if you prefer).

I don't see what you will be missing, unless you're using implementation specific API in your JPA code. I.e. do not import org.hibernate anywhere in your JPA code, but just write it against the JPA API.