Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to deploy a web application on Oracle WebLogic Server 12.2.1.1.0 [DATAJPA-1175] #1511

Closed
spring-projects-issues opened this issue Sep 5, 2017 · 5 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Sep 5, 2017

Jonas Woerlein opened DATAJPA-1175 and commented

While upgrading our application servers from WLS version 12.1.2.0.0 to 12.2.1.1.0 we have experienced problems deploying WAR-applications containing Spring Data JPA 1.11 and newer.

We created a sample application available on GitHub to reproduce the issue. To circumvent the effort of setting up WLS just to reproduce the issue, Oracle's WebCenter Portal VM can be used. It is available here. The VM's desktop contains a user manual on how to start the included WLS. Deploying the WAR file SpringDataJpaErrorSample.war to the WC_Portal server via WebLogic Administration Console will lead to this or a similar error:

An error occurred during activation of changes, please see the log for details.
java.lang.ClassNotFoundException: com.querydsl.core.types.Expression
com.querydsl.core.types.Expression

The server's log shows a stacktrace:

####<Sep 4, 2017, 3:41:50,812 PM CEST> <Error> <Deployer> <vldn496> <automation_frontend_1> <[ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'> <<W
LS Kernel>> <> <755b9b15-4dc6-4fc1-a85c-83d8bb7ac80e-00000a0a> <1504532510812> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-149265> <Failure o
ccurred in the execution of deployment request with ID "31186634096050384" for task "12" on [partition-name: DOMAIN]. Error is: "weblogic.management.DeploymentException: java.la
ng.ClassNotFoundException: com.querydsl.jpa.JPQLQuery"
weblogic.management.DeploymentException: java.lang.ClassNotFoundException: com.querydsl.jpa.JPQLQuery
        at weblogic.application.internal.BaseDeployment.throwAppException(BaseDeployment.java:132)
        at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:246)
        at weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:52)
        at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
        at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:65)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:229)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:103)
        at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:241)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:794)
        at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1340)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:267)
        at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:177)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:186)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:14)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:47)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:666)
        at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
        at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
        at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
        at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
        at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)
Caused By: java.lang.ClassNotFoundException: com.querydsl.jpa.JPQLQuery
        at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:1025)
        at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:986)
        at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:83)
        at weblogic.utils.classloaders.GenericClassLoader.doFindClass(GenericClassLoader.java:607)
        at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:539)
        at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:492)
        at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:469)
        at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:53)
        at java.lang.Class.getDeclaredFields0(Native Method)
        at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
        at java.lang.Class.getDeclaredFields(Class.java:1916)
        at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.getFields(BaseJ2eeAnnotationProcessor.java:1047)
        at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.getFields(BaseJ2eeAnnotationProcessor.java:1041)
        at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.processJ2eeAnnotations(BaseJ2eeAnnotationProcessor.java:145)
        at weblogic.j2ee.dd.xml.J2eeAnnotationProcessor.processJ2eeAnnotations(J2eeAnnotationProcessor.java:47)
        at weblogic.j2ee.dd.xml.BaseJ2eeAnnotationProcessor.processJ2eeAnnotations(BaseJ2eeAnnotationProcessor.java:120)
        at weblogic.j2ee.dd.xml.PojoAnnotationProcessorImpl.processJ2eeAnnotations(PojoAnnotationProcessorImpl.java:93)
        at weblogic.application.internal.flow.PojoAnnotationProcessingFlow.processAnnotations(PojoAnnotationProcessingFlow.java:304)
        at weblogic.application.internal.flow.PojoAnnotationProcessingFlow.processPOJOsInModuleScopes(PojoAnnotationProcessingFlow.java:229)
        at weblogic.application.internal.flow.PojoAnnotationProcessingFlow.prepare(PojoAnnotationProcessingFlow.java:73)
        at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:731)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
        at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:243)
        at weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:52)
        at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
        at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:65)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:229)
        at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:103)
        at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:241)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:794)
        at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1340)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:267)
        at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:177)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:186)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:14)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:47)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:666)
        at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
        at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
        at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
        at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
        at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)

We already contacted Oracle regarding this issue by filing a Service Request. They told us the issue is caused by increased annotation scanning requirements of CDI; therefore, more annotated classes are picked up during deployment. Oracle refuses to change this classpath scanning behaviour as they believe their approach is in accordance with the Java EE specification. We were able to identify the class org.springframework.data.jpa.repository.support.QueryDslRepositorySupport to cause the problem. It seems to be loaded by WLS during startup as one setter method is annotated with @PersistenceContext.

At the moment, we are able to use Spring Data JPA by adding Querydsl Core and JPA as dependencies as a workaround even we are not using QueryDSL in our artifacts. We think the issues poses a major pitfall for developers getting started with using Spring Data JPA on a recent version of WebLogic server and hope the Spring team can find a workaround to the issue in Spring Data JPA's code


Affects: 1.10.11 (Hopper SR11), 1.11.6 (Ingalls SR6), 2.0 RC3 (Kay), 1.11.7 (Ingalls SR7)

Reference URL: https://github.com/tngwoerleij/SpringBootAutoConfigureWlsErrorSample

Issue Links:

  • DATAJPA-1205 BeanCreationException for custom repository after upgrading to Ingalls-SR8

Referenced from: pull request #215

Backported to: 1.11.8 (Ingalls SR8), 1.10.12 (Hopper SR12)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 5, 2017

Oliver Drotbohm commented

Mark Paluch — Do you think we should be able to work around this by adding a beans.xml to the JAR that excludes our packages from component scanning? Alternatively, I think we could switch to @Autowired instead, couldn't we?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 5, 2017

Mark Paluch commented

Exclusions of scanning are supported since CDI 1.1 which should be part of WLS 12.2.1. We could ship with a beans.xml but I'd rather switch to @Autowired instead of shipping a beans.xml as the annotation-based approach seems less invasive to me and would not break CDI 1.0 applications. A beans.xml could look like:

<beans
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
                      http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
    bean-discovery-mode="all">
    <scan>
        <exclude name="org.springframework.data.repository.support.**" />
    </scan>
</beans>

Jonas Woerlein – Could you include the snippet above in your war at WEB-INF/beans.xml to see whether it addresses your issue until we ship a fix?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 5, 2017

Jonas Woerlein commented

Thanks for your fast response. Unfortunately, the problem persists even if I add abovementioned beans.xml to the WAR's WEB-INF folder

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 5, 2017

Oliver Drotbohm commented

I guess if at all, that beans.xml would need to be shipped within our JAR as CDI scans all JARs of the classpath by default (quite a mystery to me still). However, I am not sure in how far that'd interferes with the CDI support that we ship ourselves.

If I see this correctly, if we remove @PersistenceContext, we'd have to rely on the user registering an instance of the derived user class via an @Producer method manually forwarding the EntityManager. That's of course way less convenient than it was before but having to pull in Querydsl for no reason seems to be much more unfortunate

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 26, 2017

Oliver Drotbohm commented

That's in place. We removed the @PersistenceContext annotation as we don't need it ourselves

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants