4 Replies Latest reply on Jan 19, 2011 11:27 PM by obrienmi8

    Migrating Toplink Essentials/JPA 1.0 to EclipseLink/JPA 2.0 (OC4J 10.1.3)

      I'm having a bit of trouble here. The inital part of this was easy enough - changing persistence.xml to use EclipseLink persistence properties and adding Eclipselink.jar into my applib directory and then work through my unit tests to knock out bugs relating to EclipseLink being rather more strict on some aspects of relationship modelling than Toplink was. However, when I try to introduce a JPA 2.0 persistence.jar into the mix, it works (eventually) as long as I don't use any JPA 2.0 features eg EntityManager.getCriteriaBuilder. I'm using the latest EclipseLink so this is definitely supported (and it compiles and deploys fine) . I have also tried adding the persistence.jar and eclipselink.jar to the j2ee/<instancename>/applib directory and separately tried the same thing with a shared library as per this link:


      I also have tried adding -javaagent:Eclipselink jar in the JVM startup as a belt and braces to ensure the right jars are loaded, plus in my jdk/jre/lib/ext directory just in case.

      All these work so no problem there and I've removed the JPA 1.0 persistence.jar completely but if I try to make a call at runtime to, say, EntityManager.getCriteriaBuilder, I get this error:

      [junit] start fault message:
      [junit] Internal Server Error (Caught exception while handling request: oracle.oc4j.rmi.OracleRe
      moteException: java.lang.Exception: java.lang.AbstractMethodError: getCriteriaBuilder; nested except
      ion is:
      [junit] java.lang.Exception: java.lang.AbstractMethodError: getCriteriaBuilder)
      [junit] :end fault message
      [junit] java.rmi.ServerException:

      The issue seems to be the Evermind proxy class com.evermind.server.ejb.persistence.EntityManagerProxy which is loaded but doesn't define getCriteriaBuilder or other JPA 2.0 methods ie it is a JPA 1.0 class (defined in oc4j_internals.jar). i can see debugging in Eclipse that this proxy class is what is loaded by OC4J to access the JPA 2 classes so I can see why I have the problem - but not how to get round it.

      This is a different error to when I didn't have a JPA 2.0 persistence.jar loaded, when I got a NoSuchMethod exception, so I am reasonably confident (over confident?) that the right jars are loaded apart from the Oracle proxy above.

      My question is - is there any way I can use JPA 2.0 features with Eclipselink in OC4J and how, or will I have to move to another app server eg WLS ? It is part of our plan to do so but I would rather not be forced into it right now if I can get round it, as there are a lot of changes I need to make in a lot of areas to make this so - release management, ant build and deploy tasks, plus our organisations own support which is OAS-based. Can I also be sure that EclispeLink is actually using the JPA 2.0 classes here and not some JPA 1.0 classes it might be findin gin the class path (but if we are not using JPA 2.0 features, I guess that doesn't much matter - right ?)

        • 1. Re: Migrating Toplink Essentials/JPA 1.0 to EclipseLink/JPA 2.0 (OC4J 10.1.3)
          Doug Clarke-Oracle
          I do not believe any work has been done to get JPA 2.0 support certified in OC4J. It should be a matter of reconfiguring OC4J's libraries to use JPA 2.0 API jar instead of JPA 1.0.

          For now I would use EclipseLink 2.X as a JPA 1.0 provider. You can still use JPA 2.0 mappings using eclipselink-orm.xml but JPA 2.0 API such as getCriteriaBuilder() will not be available.

          If this is important to your usage of Oracle TopLink with EclipseLink I would recommend opening a support case against OC4J to escalate getting this configuration certified (or possibly not if it cannot be done through public configuration). Remember that OC4J is a Java EE 5 container that is built against JPA 1.0.

          WebLogic is also still JPA 1.0 only with the exception of packaging JPA 2.0 in your EAR with class-loader filtering and application bootstrap usage of JPA. This will be addressed in an upcoming release to allow you to use JPA 1.0.

          1 person found this helpful
          • 2. Re: Migrating Toplink Essentials/JPA 1.0 to EclipseLink/JPA 2.0 (OC4J 10.1.3)
            Thanks, Doug, that answers my question. I was kind of hoping that Weblogic might provide an answer - I presume you meant to say at the end of your post that Weblogic would be upgraded to support JPA 2.0 not 1.0 ?
            • 3. Re: Migrating Toplink Essentials/JPA 1.0 to EclipseLink/JPA 2.0 (OC4J 10.1.3)
              Yes, JPA 2.0 support in the last line.
              The option 1 section had some missing configuration (essentially the classpath was not fully defined to the 2 jars).
                        <code-source path="eclipselink.jar"/>
                        <code-source path="../shared-lib/org.eclipse.persistence/2.1.0/eclipselink.jar"/>

              The section below was updated and verified against these changes.

              I have started a new section 5 where I will post details on overriding the shipped JPA 1.0 spec jar with the JPA 2.0 version if possible for container managed and/or application managed deployments on OC4J The runtime JPA 2.0 support may include support for new 2.0 tags via the 2.0 schema in persistence.xml as well.

              I will post back to this forum when the section is complete.

              thank you
              • 4. Re: Migrating Toplink Essentials/JPA 1.0 to EclipseLink/JPA 2.0 (OC4J 10.1.3)
                See the recent OTN post from 20110115 detailing the latest release of Oracle WebLogic Server and some retesting of the previous issues related to JSR-317 JPA 2.0 support below.
                11g Release 1 Patch Set 3 (WLS 10.3.4)
                The latest release of Oracle WebLogic Server has been available on OTN at the following location since 20110115.

                This release provides support for JSR-317 JPA 2.0 container managed applications using the QWG8 patch or a manual prepending classpath change.

                In you were required to use the FilteringClassLoader via the *<wls:prefer-application-packages>* addition to your application managed persistence unit - this workaround as well as the persistence.xml renaming one is now fully deprecated and not required in for both application and container managed persistence contexts.
                As of 20110115 the 5 outstanding issues below look to be fixed by applying the http://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#EJBAD1309 patch for QWG8 or manually prepending to the WebLogic server classpath.
                commEnv.cmd: line 67
                @rem Set BEA Home
                set BEA_HOME=C:\opt\wls1034r20110115
                @rem Enable JPA 2.0 functionality on WebLogic Server 10.3.4 with the following patch line for commEnv.cmd:67
                set PRE_CLASSPATH=%BEA_HOME%\modules\javax.persistence_1.0.0.0_2-0-0.jar;%BEA_HOME%\modules\com.oracle.jpa2support_1.0.0.0_2-0.jar
                A JPA 2.0 EE application using EclipseLink as the JPA2 persistence provider on WebLogic is detailed in the analysis section below
                1) JPA 2.0 XSD parsing - verified
                2) New JPA 2.0 schema elements like <shared-cache-mode>NONE</shared-cache-mode> - verified
                3) JPA 2.0 runtime API like a entityManager.getMetamodel(); call on the Servlet or Stateless session bean - verified
                4) JPA 2.0 weaving/instrumentation - this will require a more detailed lazy model and more debugging to fully verify
                5) Dependency Injection of a container managed JPA 2.0 entityManager on a EJB component like a stateless session bean - verified
                OTN download
                Supported Oracle WebLogic Server Versions
                TopLink JPA 2.0 Specific documentation/patching
                EclipseLink Wiki: JPA 2.0 using EclipseLink on WebLogic analysis (XSD, Weaving, DI of @PersistenceContext)

                thank you
                /Michael O'Brien