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

I try to implement Hibernate in one of our applications running on Weblogic 11g and get the following error when trying to deploy when using OneToMany, OneToOne and other connection 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 on this error shows that Weblogic uses JPA 1.0 from CLASSPATH. However, we use prefer-web-inf-classes in our weblogic.xml, so I wonder why Weblogic does not prefer hibernate-jpa-2.0-api.1.0.1.Final.jar ?

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

I feel this is a terrible practice, as every application developer - current and future - will have to change their class path in order to run the application. Not to mention any similar problems encountered when deploying to intermediate and production servers.

Can anyone shed some light on this situation?

Thanks!

+4
source share
2 answers

There are two possible approaches:

  • A filtering classloader in which you tell the Weblogic classloader mechanism that certain libraries (well, indeed, packages) take precedence over those associated with Weblogic

For this approach, you must create an entry in weblogic-application.xml that indicates packages from application libraries that take precedence over Weblogic, for example, if you want to replace Antlr, you can use something like:

 <prefer-application-packages> <package-name>antlr.*</package-name> </prefer-application-packages> 
  • Deploy a shared library

From Weblogic Documentation (highlighted by me)

The WebLogic Server Java EE shared library feature provides an easy way to exchange one or more different types of Java EE modules among multiple enterprise applications. The Java EE shared library is a single module or set of modules that are registered in the Java EE application container during deployment. The Java EE shared library can be any of the following:

  • standalone EJB module
  • standalone web application module
  • multiple EJB modules packaged in an Enterprise Application
  • web application modules package in an enterprise application
  • one simple jar file

The reason that deploying the shared library will also work for your case (replacing the downloadable Weblogic library) is due to the priority order that is taken into account when using the shared library, but it would be much simpler just to use the filter class loader.

+6
source

I ran into the same problem and I had to hack weblogic.

Here is what I did:

  • Edit the file that starts the weblog server (startWebLogic.cmd) , it is located along the path, for example: C: \ Users {username} \ AppData \ Roaming \ JDeveloper \ system11.1.2.0.38.60.17 \ DefaultDomain \ BIN and add these lines to line 6 of the file. SETLOCAL

    @REM Hack JPA starts echo Hack JPA starts 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

    • This way you override the libraries used by weblogic in JPA.
  • After that, change the JPA provider in the weblogic console:

    • in the browser go to the weblogic console, as a rule, launch it in localhost: 7101 / console
    • Go to "JTA"
    • Select the "JPA" tab
    • In Default JPA Provider, select Kodo
    • Restart web server

Thus, weblogic uses new defined libs that have the correct version of the class

0
source

Source: https://habr.com/ru/post/1490782/


All Articles