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.
Related
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.
I am trying to use SpringJPA 1.10.1 which provides support for JPA 2.1 and StoredProcedureQuery class to execute procedure.
But whenever I execute the procedure, I am getting following exception:
java.lang.NoSuchMethodError: javax.persistence.EntityManager.createStoredProcedureQuery(Ljava/lang/String;)Ljavax/persistence/StoredProcedureQuery
I have checked other questions link but all are referring to weblogic 12.1.3.
Is there any way to enable JPA 2.1 with weblogic 12.1.2?
Is it safe to use the Hibernate Validator 5.0.1 with Hibernate 3.5.4? From what I've read it should not be a problem and I'm not running into any errors so far (i.e. application compiles, runs and tests pass), but I'm not sure if they fit well together.
Related Hibernate & JPA libs (inside /WEB-INF/libs):
hibernate3.jar
hibernate-annotations-3.5.4-Final.jar
hibernate-commons-annotations-3.2.0.Final.jar
hibernate-core-3.5.4-Final.jar
hibernate-entitymanager-3.5.4-Final.jar
hibernate-jpa-2.0-api-1.0.1.Final.jar
hibernate-validator-5.0.1.Final.jar
hibernate-validator-annotation-processor-5.0.1.Final.jar
validation-api-1.1.0.Final.jar
FYI:
Tomcat 7.0.39
Spring 3.0.3
PostgreSQL 9.2
Flyway 2.1.1
BoneCP 0.7.1
You should be fine with using Bean Validation 1.1/Hibernate Validator 5.0.1; Hibernate ORM depends on the Bean Validation API only, and BV 1.1 is compatible with BV 1.0.
I recommend to check the Hibernate Validator migration guide to see whether any of the issues listed there might affect you (for instances changes around logging and the usage of Java 6).
I have an app using Wicket for the presentation layer with CDI/Weld, JPA 2.0, EJB 3.1 etc. (Java EE 6) deployed on GlassFish v3.0.1.
When I try to inject an EJB into a wicket page using #EJB I get the following error:
java.lang.IllegalStateException: Unable to retrieve EntityManagerFactory for unitName
When I try to inject using #Inject, I get the following error:
java.lang.IllegalStateException: Unable to convert ejbRef for ejb UserRepository to a business object of type class
I believe the problem is stemming from JPA. I am using the exact same configuration that I used with a JSF application which worked properly, so I am lost as to what the issue could be. The connection pools are set up properly and pinging correctly through GlassFish, I have included wicket-weld on the classpath and I have even tried using the old Java EE 5 wicketstuff project for wicketstuff-javaeeapi with the same results.
Any help would be appreciated.
If you get the exception:
Unable to retrieve EntityManagerFactory for unitName
It might mean it is not detecting your persistence.xml file. Make sure it's in the WEB-INF\classes\META-INF directory.
You can verify that your app has JPA enabled by going to the Admin Console in GlassFish, go to the Applications section and see if it shows something like [ejb, web, weld, jpa] for your app. If it doesn't show jpa then it's not finding your JPA config file.
Could always try to lookup the EJB via its standard "java:global" name. That should at least let you rule out wicket as a possible source of issues and get you a little closer to a working system.
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.