Remove use of `javax.annotation.Resource`

[tngwoerleij]

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 org.springframework.boot:spring-boot-autoconfigure:1.3.0.RELEASE and newer.

We created a sample application available on GitHub to reproduce the issue: https://github.com/tngwoerleij/SpringBootAutoConfigureWlsErrorSample. To circumvent the effort of setting up WLS just to reproduce the issue, Oracle’s WebCenter Portal VM can be used. It is available at http://www.oracle.com/technetwork/middleware/webcenter/portal/downloads/owcp-vm-2251396.html. The VM’s desktop contains a user manual on how to start the included WLS. Deploying the WAR file SpringBootAutoConfigureErrorSample to the WC_Portal server via WebLogic Administration Console will lead to this error:

An error occurred during activation of changes, please see the log for details.
java.lang.ClassNotFoundException: org.springframework.security.oauth2.client.token.AccessTokenRequest
org.springframework.security.oauth2.client.token.AccessTokenRequest

The server’s log shows a stacktrace:

####<Jun 9, 2017 12:09:48 AM PDT> <Error> <Deployer> <wcp12cr2> <WC_Portal> <[STANDBY] ExecuteThread: '15' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <216b
a32e-65fd-4360-a9e0-b67c4bc38bef-000000a9> <1496992188718> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-149265> <Failure occurred in the execution 
of deployment request with ID "832883326118" for task "3" on [partition-name: DOMAIN]. Error is: "weblogic.management.DeploymentException: java.lang.ClassNotFoundException: org.springframework.security.oauth2.client.token.AccessTokenRequest"
weblogic.management.DeploymentException: java.lang.ClassNotFoundException: org.springframework.security.oauth2.client.token.AccessTokenRequest
        at weblogic.application.internal.BaseDeployment.throwAppException(BaseDeployment.java:131)
        at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:245)
        at weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:53)
        at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
        at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61)
        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:237)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:792)
        at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1306)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:264)
        at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:177)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:643)
        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:617)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:397)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)
Caused By: java.lang.ClassNotFoundException: org.springframework.security.oauth2.client.token.AccessTokenRequest
        at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:981)
        at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:942)
        at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:83)
        at weblogic.utils.classloaders.GenericClassLoader.doFindClass(GenericClassLoader.java:564)
        at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:500)
        at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:464)
        at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:441)
        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:308)
        at weblogic.application.internal.flow.PojoAnnotationProcessingFlow.processPOJOsInModuleScopes(PojoAnnotationProcessingFlow.java:233)
        at weblogic.application.internal.flow.PojoAnnotationProcessingFlow.prepare(PojoAnnotationProcessingFlow.java:77)
        at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:730)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
        at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:242)
        at weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:53)
        at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
        at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61)
        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:237)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:792)
        at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1306)
        at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:264)
        at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:177)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13)
        at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:643)
        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:617)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:397)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)

We already contacted Oracle regarding this issue by filing a Service Request. This is the response from their sustaining engineer:

We are concluding this bug for now from WLS side.

Here the exception is throwing from the Spring dependency JAR and the Exact location of the exception is while scanning/resolving the annotations in the class org.springframework.boot.autoconfigure.security.oauth2.client.OAuth2RestOperationsConfiguration$SessionScopedConfiguration$ClientContextConfiguration

@Qualifier("accessTokenRequest")
protected AccessTokenRequest accessTokenRequest;

It's not recommended to change the WLS code according to the third party.
So first we should check with the spring development team regarding the relevancy of above annotation and whether we can change anything around that.

As Oracle refuses to change their annotation processing code to mitigate this issue, our sole chance left to run Spring Boot on WLS 12.2.1.1.0 is the Spring Boot team modifying their implementation, as WLS’ code seems to be confused by the @Resource annotation on the above mentioned field when not using Spring Security OAuth and thus not having AccessTokenRequest on the classpath.

[wilkinsona]

This isn't what you want to hear, but this needs to be fixed in WebLogic. It is scanning classes for annotations that it has no need to be looking at and it is not doing so defensively. We have deployment tests for a number of other Java EE servers (GlassFish, TomEE, WebSphere Liberty, etc) and none of them have this problem.

[tngwoerleij]

We forwarded your response to Oracle and got this response with a justification of WebLogic's behaviour by Bill Shannon:

We have validated our understanding with Bill Shannon, one of our Java EE
architects. His response is below.

Explain why this is not a bug:
The platform spec says this in EE.5.2.3:

All objects defined in environment entries of any kind (either in deployment
descriptors or through annotations) must be specified to be of a Java type
that is accessible to the component.

The use of @resource in the sample app corresponds to a Resource Environment
Reference, as described in EE.5.8. EE.5.8.2 says:
The Deployer must ensure that all the declared resource environment
references are bound to administered objects that exist in the operational
environment.
EE.5.8.3 says:

At the minimum, the tools must be able to inform the Deployer of any
unresolved resource environment references, and allow him or her to resolve a
resource environment reference by binding it to a specified compatible target
object in the environment.

Taken together, I believe these require the deployment to fail in the case
you describe. This looks like an unresolved resource reference.

It has always been a goal of Java EE to detect as many errors as possible at
deployment time, to avoid applications failing unexpectedly at runtime. In
particular, there are no provisions for deploying classes that contain
resource reference errors in the hope that these classes will never be used.

We think this further reduced the chance of Oracle changing WebLogic's behaviour and hope the Spring Boot team can modify the implementation to achieve compatibility.

[snicoll]

On a second look, that @Resource shouldn't be there at all (regardless of the issue you are experiencing) so we can use that issue to fix that.