4

I am using JPA 2.0 with Spring and hibernate in my project.

However, the runtime is WAS 6.1.

Compilation goes fine.

However, during deployment of the application, I get the following error:

com.ibm.ws.exception.RuntimeError: java.lang.RuntimeException: java.lang.NoSuchMethodError: javax/persistence/spi/PersistenceUnitInfo.getValidationMode()Ljavax/persistence/ValidationMode;

On searching for PersistenceUnitInfo class using ctrl + shift + T, I found it located in the following jars:

\IBM\SDP\runtimes\base_v61\lib\j2ee.jar

and 

\WEB-INF\lib\hibernate-jpa-2.0-api-1.0.1.Final

I extracted above class from both the JARS and decompiled them using JAD for comparison.

I found that method getValidationMode() is not present in j2ee.jar but is present in the hibernate-jpa jar.

Is this the reason for the error I am getting ??? How to resolve it ?? How can I tell websphere to look for the class in the hibernate jar and not in server runtime lib ???

Vicky
  • 16,679
  • 54
  • 139
  • 232

1 Answers1

2

You cannot use JPA 2.0 with Websphere 6.1, no matter what you do. As you noticed, it's wired up into the WAS internals pretty deeply. You have two options:

  1. Migrate to WAS 7.0 with appropriate feature pack (more info in my other answer).
  2. Downgrade your Hibernate to 3.3.2 GA with JPA 1.0.
Community
  • 1
  • 1
MaDa
  • 10,511
  • 9
  • 46
  • 84
  • To be clear, you cannot use container-managed JPA with 6.1 (persistence-context/unit-ref and @PersistenceContext/UnitRef). If you use a shared library to override the JPA support, then you can still use application-managed JPA. Of course, you lose many benefits that way... – Brett Kail Oct 17 '11 at 16:27
  • @bkail But you still mean JPA 1.0, right? I'm not familiar with the 6.1 version of WAS, I was merely extrapolating based on my 7.0 experience. So it's even tougher with 6.1... – MaDa Oct 17 '11 at 18:15
  • No, if you override the JPA APIs (using a parent-last CL of some kind), then you can use whatever you want (including JPA 2.0), so long as you don't expect the container to integrate with what you provide. – Brett Kail Oct 17 '11 at 21:23
  • @bkail I don't follow what you mean by "don't expect the container to integrate": is it like "you can have it in your ear, but cannot expect it to work"? What would be the point? And I think you're wrong in suggesting one can override the built-in JPA API, because you simply can't - you'd have to carve it out of the j2ee.jar yourself. Good luck with that, it's like random .dll deletion from c:\Windows\system. – MaDa Oct 17 '11 at 21:31
  • 1
    You can override JPA APIs in your application just like you can override XML APIs. You include the JPA API JAR on your class path, and then mark the class loader as parent last (the class loader will ignore j2ee.jar, so there's no reason to modify that file). However, the JPA container assumes you won't do this, so you won't be able to use container-managed JPA (persistence-context/unit-ref and @PersistenceContext/UnitRef). I admit this is not great option, but if you're stuck on 6.1, it's your only option. – Brett Kail Oct 17 '11 at 21:37
  • @bkail Thanks for the explanation. So the question to which I now have to search answer is 'How to override WAS 6.1 Java APIs with my Application APIs?? " :) :) learning with discovering new things is great... cheers!! – Vicky Oct 20 '11 at 08:23
  • @bkail We can argue like that forever. Do share your experience when you succeed, I'll be delighted to learn how to do it. – MaDa Oct 20 '11 at 09:15
  • @NikunjChauhan Modify the mode of the class loader containing the JARs to use "parent last" (or "classes loaded with application class loader first"). For example, if the JAR is in a WAR, then the setting should be applied to the WAR module. If the JAR is in the EAR directly, then the setting should be applied to the application. If the JAR is in a shared library for a server class loader, then the setting should be applied to that server class loader. – Brett Kail Oct 20 '11 at 18:45