A brother told me today that the test environment suddenly failed to start the AdminServer, and everyone could not test it. Check the log as follows:
starting weblogic with Java version:
Starting WLS with line:
/usr/java/jdk1.6.0_29/bin/java -server -Xms2048m -Xmx2048m -Xmn768m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -verbose:gc -Xloggc:./logs/AdminServer_gc.out -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Dweblogic.threadpool.MinPoolSize=100 -Dweblogic.threadpool.MaxPoolSize=300 -Dweblogic.Name=AdminServer -Djava.security.policy=/tpsys/weblogic/wlserver_10.3/server/lib/weblogic.policy -Dweblogic.ProductionModeEnabled=true -Djava.security.egd=file:///dev/urandom -da -Dplatform.home=/tpsys/weblogic/wlserver_10.3 -Dwls.home=/tpsys/weblogic/wlserver_10.3/server -Dweblogic.home=/tpsys/weblogic/wlserver_10.3/server -Dweblogic.management.discover=true -Dwlw.iterativeDev=false -Dwlw.testConsole=false -Dwlw.logErrorsToConsole=false -Dweblogic.ext.dirs=/tpsys/weblogic/patch_wls1036/profiles/default/sysext_manifest_classpath:/tpsys/weblogic/patch_ocp371/profiles/default/sysext_manifest_classpath weblogic.Server
<Oct 26, 2016 4:11:35 PM CST> <Info> <Security> <BEA-090905> <Disabling CryptoJ JCE Provider self-integrity check for better startup performance. To enable this check, specify -Dweblogic.security.allowCryptoJDefaultJCEVerification=true>
<Oct 26, 2016 4:11:35 PM CST> <Info> <Security> <BEA-090906> <Changing the default Random Number Generator in RSA CryptoJ from ECDRBG to FIPS186PRNG. To disable this change, specify -Dweblogic.security.allowCryptoJDefaultPRNG=true>
<Oct 26, 2016 4:11:36 PM CST> <Info> <WebLogicServer> <BEA-000377> <Starting WebLogic Server with Java HotSpot(TM) 64-Bit Server VM Version 20.4-b02 from Sun Microsystems Inc.>
<Oct 26, 2016 4:11:37 PM CST> <Info> <Management> <BEA-141107> <Version: WebLogic Server 10.3.6.0 Tue Nov 15 08:52:36 PST 2011 1441050 >
<Oct 26, 2016 4:11:40 PM CST> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason: [Management:141266]Parsing Failure in config.xml: failed to find method MethodName{methodName='setCacheInAppDirectory', paramTypes=[boolean]} on class weblogic.management.configuration.AppDeploymentMBeanImpl>
<Oct 26, 2016 4:11:40 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED>
<Oct 26, 2016 4:11:40 PM CST> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down>
<Oct 26, 2016 4:11:40 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN>
Seeing this problem, the first reaction is who has broken config.xml, check it first
It turns out that the last edit date of this file was a week ago, so isn't that the problem? (begins to doubt his own judgment)
Go to Oracle official first, hey, there is really an explanation for this problem, the original text is as follows:
BEA-000362> <Server failed. Reason: [Management:141266]Parsing Failure in config.xml:
failed to find method MethodName{methodName='setCacheInAppDirectory', paramTypes=[boolean]} on class weblogic.management.configuration.AppDeploymentMBeanImpl>".
Apparently Weblogic was not happy with a config.xml file parameter and the config file was corrupted. After digging at the config.xml file we found out that for every deployment, a new <cache-in-app-directory> parameter was added to the config file. Also the recent change made by partner was rolling back a PSU that was applied to their Weblogic Server.
It seems that the first reaction is quite correct. I found it in config.xml. There is an additional parameter <cache-in-app-directory> in a server. After deleting it, start the service, normal~
Reference: https://blogs.oracle.com/imc/entry/admin_server_startup_fails_with