Weblogic: java.lang.NoSuchMethodError: javax.persistence.OneToMany.orphanRemoval()Z

4
votes

I'm attempting to implement Hibernate in one of our applications, running on Weblogic 11g, and receive the following error when attempting to deploy while using OneToMany, OneToOne, and other join tags:

java.lang.NoSuchMethodError: javax.persistence.OneToMany.orphanRemoval()Z
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:591)
        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:83)
        at gov.nysed.sedmon.common.context.ContextInitializer.initialize(ContextInitializer.java:21)
        at org.springframework.web.context.ContextLoader.customizeContext(ContextLoader.java:491)
        at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:382)
        at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
        at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
        at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:481)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
        at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:181)
        at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1872)
        at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3153)
        at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1508)
        at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:482)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
        at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
        at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
        at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:247)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
        at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
        at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27)
        at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:636)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
        at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:205)
        at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:58)
        at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161)
        at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
        at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:150)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:116)
        at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844)
        at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440)
        at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
    Caused by: java.lang.NoSuchMethodError: javax.persistence.OneToMany.orphanRemoval()Z
        at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1893)
        at org.hibernate.cfg.AnnotationBinder.processIdPropertiesIfNotAlready(AnnotationBinder.java:767)
        at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:686)
        at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3512)
        at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3466)
        at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1355)
        at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1756)
        at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1840)
        at org.springframework.orm.hibernate4.LocalSessionFactoryBuilder.buildSessionFactory(LocalSessionFactoryBuilder.java:242)
        at org.springframework.orm.hibernate4.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:372)
        at org.springframework.orm.hibernate4.LocalSessionFactoryBean.afterPropertiesSet(LocalSessionFactoryBean.java:357)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)

My research into this error shows that Weblogic is using JPA 1.0 from the CLASSPATH. However, we are using prefer-web-inf-classes in our weblogic.xml, so I'm wondering why Weblogic isn't prefering the hibernate-jpa-2.0-api.1.0.1.Final.jar?

All of the other answers/suggestions are to remove the persistence-jpa-1.0 library from the CLASSPATH, and replace it with the jpa-2.0 library.

I feel as this is a horrible practice, as every developer on the application -- current and future -- would need to modify their classpath in order to run the application. Not to mention any similar issues that would arise when deploying to the staging and production servers.

Can anyone shed some light on this situation?

Thanks!

2
javahibernatejpaweblogicweblogic11g
Maybe try prefer-application-packages instead? Hope it helps. Check here: docs.oracle.com/cd/E11035_01/wls100/programming/… – Display Name is missing
Should the weblogic-application.xml be used with a Web Application (WAR) file? I am trying to deploy to to deploy a play App and getting the exact same error. Also with 11g Release 1 (10.3.6) i found that the <prefer-application-packages> option is also available in weblogic.xml so not sure if I really need weblogic-application.xml. – Gaurav Verma
@Guarav, are you using JDeveloper? Part of my issue was weblogic-application.xml was not in the right place. I had to use the Application Resources Pane to get weblogic-application.xml included in the deployment. – Mike

2 Answers

6
votes

There are two possible approaches

  • Filtering Class Loader, where you inform Weblogic's classloader mechanism that certain libraries (well actually packages) take precedence over the ones bundled with Weblogic

For this approach you create a should create an entry on weblogic-application.xml that specifies the packages from the application libraries that take precedence over Weblogic, for example if you would like to replace Antlr you could use something like:

<prefer-application-packages>
    <package-name>antlr.*</package-name>
</prefer-application-packages>
  • Shared Library Deployment

From Weblogic's documentation (emphasis mine)

The shared Java EE library feature in WebLogic Server provides an easy way to share one or more different types of Java EE modules among multiple Enterprise Applications. A shared Java EE library is a single module or collection of modules that is registered with the Java EE application container upon deployment. A shared Java EE library can be any of the following:

  • standalone EJB module
  • standalone Web application module
  • multiple EJB modules packaged in an Enterprise Application
  • multiple Web application modules package in an Enterprise Application
  • single plain JAR file

The reason why a Shared Library Deployment would also work for your case (replacement of Weblogic's shipped library) is because of the order of precedence that is taken into consideratrion when using a Shared Library, but it would be much simpler to just use a Filtering Class Loader.

0
votes

I was facing the same problem and I had to hack weblogic.

Thats what I did:

  1. Edit the file that starts weblogic server (startWebLogic.cmd), this is located in a path like: C:\Users{username}\AppData\Roaming\JDeveloper\system11.1.2.0.38.60.17\DefaultDomain\bin and add this lines in the line 6 of the file. SETLOCAL

    @REM Hack JPA begin echo Hack JPA begin set wls_modules=C:\oracle\Middleware\modules set PRE_CLASSPATH=%wls_modules%\javax.persistence_1.0.0.0_2-0-0.jar;%wls_modules%\com.oracle.jpa2support_1.0.0.0_2-0.jar; echo PRE_CLASSPATH=%PRE_CLASSPATH% echo Hack JPA End @REM Hack JPA END

    • That way you override the libs that weblogic use in JPA.

  2. After that, modify the JPA provider in the weblogic console:

    • in the browser go to weblogic console, normally its running in localhost:7101/console
    • Go to "JTA"
    • Select the "JPA" tab
    • In the "Default JPA Provider" select "Kodo"
    • Restart weblogic server

In that way weblogic uses the new libs defined which had the correct version of the Class