I am seeing an exception at the start of weblogic 10.3.x application. Log4j2 version: 2.6.1
Below mentioned log4j xml configuration I am using and stacktrace.
Log4j2.xml
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO" >
<Properties>
<Property name="theHostName">${hostName}</Property>
</Properties>
<Appenders>
<RollingFile name="FILE" filename="${sys:weblogic.Name}.log" filepattern="${sys:weblogic.Name}.log.%i" append="true" >
<PatternLayout pattern="[%-5p][%d{yyyy-MM-dd HH:mm:ss,SSS}][${sys:weblogic.Name}:${hostName}][%t][%X{MessageInfo}][%c{1}:%M:%L][%msg]%n" />
<Policies>
<SizeBasedTriggeringPolicy size="50 MB" />
</Policies>
<DefaultRolloverStrategy max="100" fileIndex="min"/>
</RollingFile>
</Appenders>
<Loggers>
<AsyncLogger level="INFO" name="com.company" includeLocation="true" additivity="false">
<AppenderRef ref="FILE"/>
</AsyncLogger>
<Root level="INFO" includeLocation="true">
<AppenderRef ref="FILE"/>
</Root>
<!-- Package specific log level defines -->
<Logger level="WARN" name="org.springframework" />
<Logger level="WARN" name="org.jboss" />
<Logger level="OFF" name="org.hibernate" />
<Logger level="WARN" name="com.company.project.eligibility" />
</Loggers>
</Configuration>
Exception occuring at beginning of server start:
2016-08-26 02:19:15,172 [ACTIVE] ExecuteThread: '13' for queue:
'weblogic.kernel.Default (self-tuning)' ERROR Could not
unregister MBeans for org.apache.logging.log4j2:type=AsyncContext@694ae32f,
component=AsyncLoggerRingBuffer javax.management.InstanceNotFoundException:
org.apache.logging.log4j2:type=AsyncContext@694ae32f,
component=AsyncLoggerRingBuffer
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546)
at org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335)
at org.apache.logging.log4j.core.jmx.Server.unregisterAsyncLoggerRingBufferAdmins(Server.java:316)
at org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:258)
at org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:162)
at org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:138)
at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:502)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
at org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
at com.company.tns.netmessage.bean.NetMessageListener.<clinit>(NetMessageListener.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:383)
at com.oracle.pitchfork.spi.bean.internal.GeneralBeanManager.getBean(GeneralBeanManager.java:22)
at com.oracle.pitchfork.spi.EjbComponentCreatorBrokerImpl.getBean(EjbComponentCreatorBrokerImpl.java:82)
at weblogic.ejb.container.injection.EjbComponentCreatorImpl.getBean(EjbComponentCreatorImpl.java:57)
at weblogic.ejb.container.manager.BaseEJBManager.createNewBeanInstance(BaseEJBManager.java:220)
at weblogic.ejb.container.manager.BaseEJBManager.allocateBean(BaseEJBManager.java:235)
at weblogic.ejb.container.manager.MessageDrivenManager.createBean(MessageDrivenManager.java:301)
at weblogic.ejb.container.pool.MessageDrivenPool.createBean(MessageDrivenPool.java:174)
at weblogic.ejb.container.pool.Pool.createInitialBeans(Pool.java:299)
at weblogic.ejb.container.manager.MessageDrivenManager.start(MessageDrivenManager.java:655)
at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl$DestinationResovler.activateNoneDDMDManager(MessageDrivenBeanInfoImpl.java:2356)
at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl$QueueConnectionHandler.handleNoneDD(MessageDrivenBeanInfoImpl.java:2798)
at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl$DestinationResovler.resolveDestnationWorkMode(MessageDrivenBeanInfoImpl.java:2289)
at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl$DestinationEventHandler.onDestinationsAvailable(MessageDrivenBeanInfoImpl.java:2112)
at weblogic.jms.extensions.JMSDestinationAvailabilityHelper$DestinationAvailabilityListenerWrapper$2.run(JMSDestinationAvailabilityHelper.java:386)
at weblogic.jms.extensions.JMSDestinationAvailabilityHelper$DestinationAvailabilityListenerWrapper.callOutListener(JMSDestinationAvailabilityHelper.java:402)
at weblogic.jms.extensions.JMSDestinationAvailabilityHelper$DestinationAvailabilityListenerWrapper.onDDMembershipChange(JMSDestinationAvailabilityHelper.java:383)
at weblogic.jms.common.CDS$DD2Listener.run(CDS.java:1264)
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)
What does this Cryptic error mean and how do I fix it?
The error means Weblogic barfed when log4j tried to unregister a JMX MBean that had not been registered.
Log4j catches this error and logs it at ERROR level including the stack trace. The application then continues to do its work. So there is no real problem and this is more like a noisy alert.
You can try to reduce the noise by telling log4j to disable JMX by setting system property log4j2.disable.jmx=true.
Furthermore you could argue that log4j should change the error handling to display a less scary looking message. You can request this change on the log4j2 Jira issue tracker.
Update:
I raised https://issues.apache.org/jira/browse/LOG4J2-1581 for this issue. This is now fixed in master and will be included in the next release, Log4j 2.7.