Develop Reference

java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurity

We have spring mvc application in which we implemented JWT authentication. It is working fine in local environment but getting below error after deploying as a war file in linux server. Facing this issue for few API calls only some APIs are working fine with out any error.
I have checked policy jars already available
/jre/lib/security/policy/unlimited/US_export_policy.jar
/jre/lib/security/policy/unlimited/local_policy.jar
/jre/lib/security/policy/limited/US_export_policy.jar
/jre/lib/security/policy/limited/local_policy.jar
500 Internal Server Error: Root Cause
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurity
javax.crypto.Mac.getInstance(Mac.java:176)
io.jsonwebtoken.impl.crypto.MacSigner.doGetMacInstance(MacSigner.java:64)
io.jsonwebtoken.impl.crypto.MacSigner.getMacInstance(MacSigner.java:53)
io.jsonwebtoken.impl.crypto.MacSigner.sign(MacSigner.java:47)
io.jsonwebtoken.impl.crypto.MacValidator.isValid(MacValidator.java:33)
io.jsonwebtoken.impl.crypto.DefaultJwtSignatureValidator.isValid(DefaultJwtSignatureValidator.java:61)
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:408)
io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:541)
io.jsonwebtoken.impl.DefaultJwtParser.parseClaimsJws(DefaultJwtParser.java:601)
io.jsonwebtoken.impl.ImmutableJwtParser.parseClaimsJws(ImmutableJwtParser.java:173)
com.gsshop.api.jwt.JWTManager.validateJwtToken(JWTManager.java:66)

Connect Java Mission Control to Wildfly 16

I try to connect Java Mission Control (JMC) with Wildfly 16. Application server lays on Docker.
I successfully connected to wildfly via jconsole, to manage it I followed steps described here.
Unfortunately, I have no luck to connect via JMC. The URL which I use looks like this:
service:jmx:remoting-jmx://192.168.99.100:9990
I tried to set Xbootclasspath to jboss-cli-client.jar as it was described here, but I just get Unable to connect error.
I set the same jars, which are used for jconsole, but still I got Unable to connect.
I gave a try to adding flags on container site, as it was shown here, but with these flags, even wildfly haven't started.
Then, I found here the idea to hardcode some jboss classes to enable connection via remoting-jmx. I changed version of jars, according to these provided by wildfly16 and put it to jmc.ini like this.
-Xbootclasspath/a:"C:/Program Files/Java/jdk-10.0.2/lib/missioncontrol/dropins/jboss-cli-client.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting-jmx/main/remoting-jmx-3.0.1.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting/main/jboss-remoting-5.0.8.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logging/main/jboss-logging-3.3.2.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/main/xnio-api-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/nio/main/xnio-nio-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/main/jboss-marshalling-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/river/main/jboss-marshalling-river-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/cli/main/wildfly-cli-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/staxmapper/main/staxmapper-1.3.0.Final;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/protocol/main/wildfly-protocol-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/dmr/main/jboss-dmr-1.5.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/controller-client/main/wildfly-controller-client-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/threads/main/jboss-threads-2.3.3.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.7.Final.jar"
After that, finally, I have another error, which is
Could not initialize class org.jboss.remotingjmx.RemotingConnector
I added dependencies of remoting-jmx-3.0.1.Final to Xbootclasspath, but I got still the same error.
My question is, have you got any idea, how to make this connection works ? Maybe someone have done it in different way ?
Any advices how can i debug this problem, will be priceless? Because I'm lack of ideas how to solve it.

In %WILDFLY_HOME%\bin\standalone.conf.bat
put:
set "JAVA_OPTS=%JAVA_OPTS% -XX:+FlightRecorder"
In jmc.ini below -vmargs put
-Xbootclasspath/a:C:\%wildfly_home%\bin\client\jboss-cli-client.jar
(%wildfly_home% is different of course, or just copy jboss-cli-client.jar to another directory and correct the path)
3. Run JMC, then Create New Connection - in Connection Properties pane push the button "Custom JMX service URL", put:
service:jmx:http-remoting-jmx://localhost:9990
In the credentials fields just put user and password, they should be created for Realm Management (e.g. using %wildfly_home%\bin\add-user.bat)
Hope this helps someone.

Solution doesn't work on java 11 for me. Mission control fails on connect to wildfly with error:
Caused by: java.lang.NoClassDefFoundError: org/ietf/jgss/GSSManager
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
at java.base/java.lang.Class.getConstructor0(Class.java:3342)
at java.base/java.lang.Class.getConstructor(Class.java:2151)
at java.base/java.security.Provider.newInstanceUtil(Provider.java:152)
at java.base/java.security.Provider$Service.newInstance(Provider.java:1824)
at org.wildfly.security.WildFlyElytronBaseProvider$ProviderService.newInstance(WildFlyElytronBaseProvider.java:218)
at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:94)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:76)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64)
at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1545)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:430)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:419)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:244)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Besides, jmc that was embedded to jdk 8 isn't able to start flight recording for java 11 process.
So after investigation i found out that this class is loaded with bootstrap classloader. According to https://openjdk.java.net/jeps/261
jdk.security.jgss module isn't defined to bootstrap classloader. But classes in jboss-cli-client.jar(it originates from wildfly-elytron project) need jgss classes in runtime.
So i found out dirty workaround for this problem: bootstrap needed classes from jre 8 in jmc.ini. Full option for linux is:
-vmargs -Xbootclasspath/a:<path_to_wildfly>/jboss-cli-client.jar:<path_to_jdk8>/jre/lib/rt.jar
And for windows:
-vmargs -Xbootclasspath/a:<path_to_wildfly>\jboss-cli-client.jar;<path_to_jdk8>\jre\lib\rt.jar
after this jmc(run on 11 jdk) succesfully connects to wildfly(run on 11 jdk) and can start and analyze flight recordings.

Deploying a maven EAR application through netbeans to glassfish fails

I am trying to deploy a maven EAR application to a Glassfish 3 server through Netbeans using right click -> debug and it fails with: GlassFish Server, deploy, Error writing request body to server, false
The output is:
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 0.977 s
Finished at: 2017-10-02T21:00:19+03:00
Final Memory: 9M/393M
------------------------------------------------------------------------
Deploying on GlassFish Server
profile mode: false
debug mode: false
force redeploy: true
Distributing /path/to/ear.ear
GlassFish Server, deploy, Error writing request body to server, false
The Glassfish log contains no logging information.
The Netbeans IDE log contains the following:
INFO [glassfish]: Requested Entity: public id = -//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN, system id = http://glassfish.org/dtds/glassfish-resources_1_5.dtd
INFO [null]: Last record repeated again.
WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save()
INFO [org.netbeans.modules.glassfish.tooling.admin.RunnerHttpDeploy]: IO exception caught in handleSend() method:
java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:3518)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:3501)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:255)
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
[catch] at org.netbeans.modules.glassfish.tooling.admin.RunnerHttpDeploy.handleSend(RunnerHttpDeploy.java:267)
at org.netbeans.modules.glassfish.tooling.admin.Runner.handleHTTPConnection(Runner.java:828)
at org.netbeans.modules.glassfish.tooling.admin.Runner.call(Runner.java:939)
at org.netbeans.modules.glassfish.tooling.admin.Runner.call(Runner.java:73)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
INFO [org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment]
The module has not been deployed.
See the server log for details.
[catch] at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:259)
at org.netbeans.modules.maven.j2ee.execution.DeploymentHelper.perform(DeploymentHelper.java:208)
at org.netbeans.modules.maven.j2ee.execution.CoSAlternativeExecutorImpl.execute(CoSAlternativeExecutorImpl.java:90)
at org.netbeans.modules.maven.cos.CoSAlternativeExecutor.execute(CoSAlternativeExecutor.java:87)
at org.netbeans.modules.maven.cos.CosChecker.checkRunMainClass(CosChecker.java:209)
at org.netbeans.modules.maven.cos.CosChecker.checkRunConfig(CosChecker.java:163)
at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:225)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
INFO [glassfish]: Requested Entity: public id = -//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN, system id = http://glassfish.org/dtds/glassfish-resources_1_5.dtd
INFO [null]: Last record repeated again.
WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save()
INFO [org.netbeans.modules.glassfish.tooling.admin.RunnerHttpDeploy]: IO exception caught in handleSend() method:
java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:3518)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:3501)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:126)
at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:255)
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
[catch] at org.netbeans.modules.glassfish.tooling.admin.RunnerHttpDeploy.handleSend(RunnerHttpDeploy.java:267)
at org.netbeans.modules.glassfish.tooling.admin.Runner.handleHTTPConnection(Runner.java:828)
at org.netbeans.modules.glassfish.tooling.admin.Runner.call(Runner.java:939)
at org.netbeans.modules.glassfish.tooling.admin.Runner.call(Runner.java:73)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
INFO [org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment]
The module has not been deployed.
See the server log for details.
[catch] at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:259)
at org.netbeans.modules.maven.j2ee.execution.DeploymentHelper.perform(DeploymentHelper.java:208)
at org.netbeans.modules.maven.j2ee.execution.ExecutionChecker.executionResult(ExecutionChecker.java:93)
at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:315)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
Netbeans version: 8.2
Glassfish version: 3.1.2.2 (build 5)
Platform: reproducible on both Windows10 + Debian9
Maven version: 3.3.9
JDK: 1.7.0_80
Glassfish secure admin is enabled
The EAR produced can be normally deployed to Glassfish using the asadmin command. It is only when trying to deploy it through Netbeans that it fails so.
EDIT
It seems that when secure admin is disabled i am able to perform the deployment through Netbeans. I have come across some problems with the secure admin and ssl.
This is the best answer i could find that described the issue i am experiencing: https://intellij-support.jetbrains.com/hc/en-us/community/posts/206913035-Glassfish-3-1-remote-deploy-not-working (even though it is for another IDE).
This is not an accepted solution though because the secure admin is a requirement for everyday dev work.
EDIT 2
After experimenting a bit more i have observed the following:
Since the Glassfish logs are empty, and the netbeans IDE log contains an error having to do with HttpUrlConnection i think that after netbeans finishes the build process it fails to write the EAR to the socket.
I have experimented with other EAR projects (generated a new maven EAR from netbeans) and it deploys OK to Glassfish.
I have come across an article that mentions a bug in Netbeans failing to write archives of a certain size. I have tried to generate a new maven project with a large final EAR size but it deploys OK. The bug is quite old and has since been fixed: https://netbeans.org/bugzilla/show_bug.cgi?id=206946
EDIT 3
After experimenting with the POM file and removing all dependencies and trying adding one by one back in it seems that this issue is triggered by the inclusion of an EJB dependency.
Including a depencency of type ejb and declaring it as an ejbModule in the maven ear plugin modules section seems to be triggering the issue.
<dependency>
<groupId>com.foo</groupId>
<artifactId>BAR</artifactId>
<version>1.0</version>
<type>ejb</type>
</dependency>
.
.
.
.
<ejbModule>
<groupId>com.foo</groupId>
<artifactId>BAR</artifactId>
<altDeploymentDescriptor>AltDD.xml</altDeploymentDescriptor>
</ejbModule>
I still don't know why this issue is triggered. I have read online that there might be an issue with file size but i have been unable to reproduce it.

This might be happening on Netbeans when stopped on a breakpoint, and then some deployments might tend to fail immediately.
The BUG-253630 mentions a reproducible scenario for such as use case:-
1. Run app with DoS off (DoS state MODULE_NOT_DEPLOYED)
2. Debug it
3. App stopped at breakpoint
4. Change source (DoS state SERVER_STATE_UNSUPPORTED)
5. Continue with the app (release breakpoint, detach JPDA)
6. Change source (DoS state MODULE_UPDATED)
Also, make sure that for remote administration you will have to set an admin password before performing the actual enabling:
asadmin change-admin-password --domain_name [DOMAIN_NAME]
asadmin enable-secure-admin --port [PORT_NAME]
..and apart from just that, you can even try setting the password as empty if that might help as well.

JCaptcha and the SpringFramework

I have created REST API for captcha - using JCaptcha in spring framework.
Everything works fine when i place the war file inside tomcat7 server present in windows OS environment.
For deployment, when i use same war file in tomcat7 web server which present in Ubuntu 14.04 the api suddenly start giving http 500 response code with following exception :
org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.lang.NoClassDefFoundError: Could not initialize class sun.awt.image.codec.JPEGImageEncoderImpl
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:820)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
com.televital.vitalware.services.CORSFilter.doFilterInternal(CORSFilter.java:29)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
I have reffered following link for the development of the API
https://jcaptcha.atlassian.net/wiki/display/general/JCaptcha+and+the+SpringFramework
Please help me.It alredy took my 2 days.

There are two possibilities.
sun.awt.image.codec.* is included in <JDK installation
folder>\jre\lib\rt.jar. So check this jar is already existed in your
Linux machine or not.
The second one is you need to turn on Headless mode in your Linux machine.Before you run tomcat startup script, you need to turn on Headless mode like this
JAVA_OPTS='-Djava.awt.headless=true'

From the stack trace its evident that on Ubuntu the application is not able to locate the sun.awt.image.codec.JPEGImageEncoderImpl class from <JDK installation>\jre\lib\rt.jar.
To resolve the error check below
JDK is installed correctly (if not re-install)
JAVA_HOME is configured correctly
If above two are correct then use headless mode by specifying -Djava.awt.headless=true

java.io.IOException: [DeploymentService:290066]Error occurred while downloading files from Administration Server for deployment request

I am getting the below error while deploying the ear in the weblogic server through jenkins. Ear deployment is getting stuck showing "deploy Running".
java.io.IOException: [DeploymentService:290066]Error occurred while downloading files from Administration Server for deployment request "1,458,644,837,675". Underlying error is: "null"
at weblogic.deploy.service.datatransferhandlers.HttpDataTransferHandler.getDataAsStream(HttpDataTransferHandler.java:86)
at weblogic.deploy.service.datatransferhandlers.DataHandlerManager$RemoteDataTransferHandler.getDataAsStream(DataHandlerManager.java:153)
at weblogic.deploy.internal.targetserver.datamanagement.AppDataUpdate.doDownload(AppDataUpdate.java:39)
at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.download(DataUpdate.java:56)
at weblogic.deploy.internal.targetserver.datamanagement.Data.prepareDataUpdate(Data.java:97)
at weblogic.deploy.internal.targetserver.BasicDeployment.prepareDataUpdate(BasicDeployment.java:694)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepareDataUpdate(AbstractOperation.java:913)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.stageFilesFromAdminServer(AbstractOperation.java:276)
at weblogic.deploy.internal.targetserver.DeploymentManager.createOperations(DeploymentManager.java:1409)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleUpdateDeploymentContext(DeploymentManager.java:162)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.updateDeploymentContext(DeploymentServiceDispatcher.java:155)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doUpdateDeploymentContextCallback(DeploymentReceiverCallbackDeliverer.java:147)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.updateDeploymentContext(DeploymentReceiverCallbackDeliverer.java:28)
at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.callDeploymentReceivers(ReceivedPrepare.java:203)
at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.handlePrepare(ReceivedPrepare.java:112)
at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.receivedPrepare(ReceivedPrepare.java:52)
at weblogic.deploy.service.internal.targetserver.TargetRequestImpl.run(TargetRequestImpl.java:211)
at weblogic.deploy.service.internal.transport.CommonMessageReceiver$1.run(CommonMessageReceiver.java:457)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

We had almost the same error and after a brief investigation found out our newly created server doesn't have every auth it needed. I know it's a bit old thread but it might help to somebody.

check the permission inside tmp folder of admin and managed server where code is deployed. ownership should be with the same id with which code is getting deployed.