[JBoss JIRA] (JBAS-9318) BridgeLogger doesn't support addAppender, getAppender and other methods available to a log4j Logger
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBAS-9318?page=com.atlassian.jira.plugin.... ]
David Lloyd updated JBAS-9318:
------------------------------
Assignee: (was: David Lloyd)
> BridgeLogger doesn't support addAppender, getAppender and other methods available to a log4j Logger
> ---------------------------------------------------------------------------------------------------
>
> Key: JBAS-9318
> URL: https://issues.jboss.org/browse/JBAS-9318
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 6.0.0.Final
> Reporter: Richard Robinson
>
> The JBoss 6 BridgeLogger is missing some functionality of the log4j Logger class that our app needs to dynamically reconfigure the logger. We need this primarily because we want to send error logging to only an error appender if tracing if off and, if tracing is on, we want to send error logging to both an error appender and also to the trace appender. The idea is that the error log always only shows errors and that the trace log will show both tracing and errors.
> To make this work programmatically we use the Logger getAllAppenders, getAppender, setAppender, removeAppender and setLevel calls. Unfortunately, only the setLevel call seems to work in the current BridgeLogger implementation and the other methods apparently do nothing.
> Although we are using the log4j API, it might be helpful to illustrate the configuration in jboss-logging.xml terms. We want to be able to set up a configuration that is effectively like this if tracing is off:
> {code:xml}
> <logger category="errors">
> <handlers>
> <handler-ref name="CONSOLE"/>
> <handler-ref name="ERROR"/>
> </handlers>
> </logger>
> <logger category="tracing">
> <level name="OFF"/>
> <handlers>
> <handler-ref name="TRACING"/>
> </handlers>
> </logger>
> {code}
> So if tracing is turned off, the error logger goes to the error appender/handler and the console.
> However, if tracing is turned on. We want to dynamically set to something like this (again this is in effective jboss-logging.xml terms... we actually do make the changes using the log4j API):
> {code:xml}
> <logger category="errors">
> <handlers>
> <handler-ref name="CONSOLE"/>
> <handler-ref name="ERROR"/>
> <handler-ref name="TRACING"/>
> </handlers>
> </logger>
> <logger category="tracing">
> <level name="DEBUG"/>
> <handlers>
> <handler-ref name="TRACING"/>
> </handlers>
> </logger>
> {code}
> The difference is that now the error logger now has a new appender/handler for TRACING which wasn't there for the tracing off case. Also the tracing logger is now set to level DEBUG.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBAS-9318) BridgeLogger doesn't support addAppender, getAppender and other methods available to a log4j Logger
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBAS-9318?page=com.atlassian.jira.plugin.... ]
David Lloyd updated JBAS-9318:
------------------------------
Description:
The JBoss 6 BridgeLogger is missing some functionality of the log4j Logger class that our app needs to dynamically reconfigure the logger. We need this primarily because we want to send error logging to only an error appender if tracing if off and, if tracing is on, we want to send error logging to both an error appender and also to the trace appender. The idea is that the error log always only shows errors and that the trace log will show both tracing and errors.
To make this work programmatically we use the Logger getAllAppenders, getAppender, setAppender, removeAppender and setLevel calls. Unfortunately, only the setLevel call seems to work in the current BridgeLogger implementation and the other methods apparently do nothing.
Although we are using the log4j API, it might be helpful to illustrate the configuration in jboss-logging.xml terms. We want to be able to set up a configuration that is effectively like this if tracing is off:
{code:xml}
<logger category="errors">
<handlers>
<handler-ref name="CONSOLE"/>
<handler-ref name="ERROR"/>
</handlers>
</logger>
<logger category="tracing">
<level name="OFF"/>
<handlers>
<handler-ref name="TRACING"/>
</handlers>
</logger>
{code}
So if tracing is turned off, the error logger goes to the error appender/handler and the console.
However, if tracing is turned on. We want to dynamically set to something like this (again this is in effective jboss-logging.xml terms... we actually do make the changes using the log4j API):
{code:xml}
<logger category="errors">
<handlers>
<handler-ref name="CONSOLE"/>
<handler-ref name="ERROR"/>
<handler-ref name="TRACING"/>
</handlers>
</logger>
<logger category="tracing">
<level name="DEBUG"/>
<handlers>
<handler-ref name="TRACING"/>
</handlers>
</logger>
{code}
The difference is that now the error logger now has a new appender/handler for TRACING which wasn't there for the tracing off case. Also the tracing logger is now set to level DEBUG.
was:
The JBoss 6 BridgeLogger is missing some functionality of the log4j Logger class that our app needs to dynamically reconfigure the logger. We need this primarily because we want to send error logging to only an error appender if tracing if off and, if tracing is on, we want to send error logging to both an error appender and also to the trace appender. The idea is that the error log always only shows errors and that the trace log will show both tracing and errors.
To make this work programmatically we use the Logger getAllAppenders, getAppender, setAppender, removeAppender and setLevel calls. Unfortunately, only the setLevel call seems to work in the current BridgeLogger implementation and the other methods apparently do nothing.
Although we are using the log4j API, it might be helpful to illustrate the configuration in jboss-logging.xml terms. We want to be able to set up a configuration that is effectively like this if tracing is off:
<logger category="errors">
<handlers>
<handler-ref name="CONSOLE"/>
<handler-ref name="ERROR"/>
</handlers>
</logger>
<logger category="tracing">
<level name="OFF"/>
<handlers>
<handler-ref name="TRACING"/>
</handlers>
</logger>
So if tracing is turned off, the error logger goes to the error appender/handler and the console.
However, if tracing is turned on. We want to dynamically set to something like this (again this is in effective jboss-logging.xml terms... we actually do make the changes using the log4j API):
<logger category="errors">
<handlers>
<handler-ref name="CONSOLE"/>
<handler-ref name="ERROR"/>
<handler-ref name="TRACING"/>
</handlers>
</logger>
<logger category="tracing">
<level name="DEBUG"/>
<handlers>
<handler-ref name="TRACING"/>
</handlers>
</logger>
The difference is that now the error logger now has a new appender/handler for TRACING which wasn't there for the tracing off case. Also the tracing logger is now set to level DEBUG.
> BridgeLogger doesn't support addAppender, getAppender and other methods available to a log4j Logger
> ---------------------------------------------------------------------------------------------------
>
> Key: JBAS-9318
> URL: https://issues.jboss.org/browse/JBAS-9318
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 6.0.0.Final
> Reporter: Richard Robinson
> Assignee: David Lloyd
>
> The JBoss 6 BridgeLogger is missing some functionality of the log4j Logger class that our app needs to dynamically reconfigure the logger. We need this primarily because we want to send error logging to only an error appender if tracing if off and, if tracing is on, we want to send error logging to both an error appender and also to the trace appender. The idea is that the error log always only shows errors and that the trace log will show both tracing and errors.
> To make this work programmatically we use the Logger getAllAppenders, getAppender, setAppender, removeAppender and setLevel calls. Unfortunately, only the setLevel call seems to work in the current BridgeLogger implementation and the other methods apparently do nothing.
> Although we are using the log4j API, it might be helpful to illustrate the configuration in jboss-logging.xml terms. We want to be able to set up a configuration that is effectively like this if tracing is off:
> {code:xml}
> <logger category="errors">
> <handlers>
> <handler-ref name="CONSOLE"/>
> <handler-ref name="ERROR"/>
> </handlers>
> </logger>
> <logger category="tracing">
> <level name="OFF"/>
> <handlers>
> <handler-ref name="TRACING"/>
> </handlers>
> </logger>
> {code}
> So if tracing is turned off, the error logger goes to the error appender/handler and the console.
> However, if tracing is turned on. We want to dynamically set to something like this (again this is in effective jboss-logging.xml terms... we actually do make the changes using the log4j API):
> {code:xml}
> <logger category="errors">
> <handlers>
> <handler-ref name="CONSOLE"/>
> <handler-ref name="ERROR"/>
> <handler-ref name="TRACING"/>
> </handlers>
> </logger>
> <logger category="tracing">
> <level name="DEBUG"/>
> <handlers>
> <handler-ref name="TRACING"/>
> </handlers>
> </logger>
> {code}
> The difference is that now the error logger now has a new appender/handler for TRACING which wasn't there for the tracing off case. Also the tracing logger is now set to level DEBUG.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBAS-7969) XB binding of org.jboss.logging.metadata.HandlerMetaData.propertyMetaDataList
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBAS-7969?page=com.atlassian.jira.plugin.... ]
David Lloyd updated JBAS-7969:
------------------------------
Assignee: (was: David Lloyd)
> XB binding of org.jboss.logging.metadata.HandlerMetaData.propertyMetaDataList
> -----------------------------------------------------------------------------
>
> Key: JBAS-7969
> URL: https://issues.jboss.org/browse/JBAS-7969
> Project: Application Server 3 4 5 and 6
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 6.0.0.M2
> Reporter: Alexey Loubyansky
> Fix For: No Release
>
>
> Property order is not specified for type org.jboss.beans.metadata.spi.PropertyMetaData bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: value preInstantiate type name
> at org.jboss.logging.metadata.HandlerMetaData.propertyMetaDataList
> at org.jboss.logging.metadata.LoggingMetaData.handlerMetaDataList
> at org.jboss.logging.metadata.LoggingMetaData
> @XmlElementWrapper(name="properties")
> public void setPropertyMetaDataList(final List<PropertyMetaData> propertyMetaDataList) {
> this.propertyMetaDataList = propertyMetaDataList;
> }
> PropertyMetaData is an interface and an implementation class must be specified. It's not actually used, is it?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBAS-8312) Exception when trying to specify ear-specific log
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBAS-8312?page=com.atlassian.jira.plugin.... ]
David Lloyd updated JBAS-8312:
------------------------------
Assignee: (was: David Lloyd)
> Exception when trying to specify ear-specific log
> -------------------------------------------------
>
> Key: JBAS-8312
> URL: https://issues.jboss.org/browse/JBAS-8312
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: 6.0.0.M3
> Environment: Windows, JDK 1.6
> Reporter: Greg Zoller
> Fix For: No Release
>
>
> I get the exception below when trying to specify my own log file for my trivial EJB EAR. My jboss-logging.jar is provided below.
> The exception happens while the server is coming up and the EAR is loaded, but before any attempt to access or use the log occurs.
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- My application jboss-logging.xml -->
> <logging xmlns="urn:jboss:logging:6.0" context="com.myco.apps">
> <!--
> ~ This element, in conjunction with the "context" attribute above, tells the
> ~ logging system that I want my own separate logging environment.
> -->
> <define-context name="com.myco.apps"/>
> <!-- Just an example handler. -->
> <file-handler file-name="/logs/constellation/foo.log" name="FILE" autoflush="true" append="true">
> <formatter>
> <pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
> </formatter>
> <!--
> <properties>
> <property name="encoding">UTF-8</property>
> </properties>
> -->
> </file-handler>
> <!-- Configure the root logger with my handler from above -->
> <root-logger>
> <level name="INFO"/>
> <handlers>
> <handler-ref name="FILE"/>
> </handlers>
> </root-logger>
> </logging>
> 13:05:56,284 ERROR [AbstractKernelController] Error installing to Instantiated: name=Logging:CONTEXT:com.aviall.apps state=Described: java.lang.IllegalAccessException: Class org.jboss.reflect.plugins.introspection.ReflectionUtils can not access a member of class org.jboss.logmanager.LogContext with modifiers ""
> at sun.reflect.Reflection.ensureMemberAccess(Unknown Source) [:1.6.0_20]
> at java.lang.reflect.Constructor.newInstance(Unknown Source) [:1.6.0_20]
> at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:149) [jboss-reflect.jar:2.2.0.Alpha4]
> at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:107) [jboss-reflect.jar:2.2.0.Alpha4]
> at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:81) [jboss-reflect.jar:2.2.0.Alpha4]
> at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:109) [jboss-aop-mc-int.jar:2.2.0.Alpha9]
> at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.Alpha9]
> at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.Alpha9]
> at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.Alpha9]
> at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.Alpha9]
> at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:67) [jboss-kernel.jar:2.2.0.Alpha9]
> at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha9]
> at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:892) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:639) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:180) [:2.2.0.Alpha4]
> at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.Alpha4]
> at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha4]
> at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha4]
> at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha4]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1857) [:2.2.0.Alpha4]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1575) [:2.2.0.Alpha4]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1596) [:2.2.0.Alpha4]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1516) [:2.2.0.Alpha4]
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:937) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:652) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:2008) [:2.2.0.Alpha4]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1101) [:2.2.0.Alpha4]
> at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha4]
> at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) [:6.0.0.20100429-M3]
> at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) [:6.0.0.20100429-M3]
> at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) [:6.0.0.20100429-M3]
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403) [:6.0.0.20100429-M3]
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:892) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:639) [jboss-dependency.jar:2.2.0.Alpha9]
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308) [:6.0.0.20100429-M3]
> at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256) [:6.0.0.20100429-M3]
> at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:97) [:6.0.0.20100429-M3]
> at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
> at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
> at java.lang.Thread.run(Unknown Source) [:1.6.0_20]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JBAS-8261) Finalizer and Timer-Log4jService threads deadlock
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBAS-8261?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved JBAS-8261.
-------------------------------
Resolution: Out of Date
I have no plans to resolve this issue at this time.
> Finalizer and Timer-Log4jService threads deadlock
> -------------------------------------------------
>
> Key: JBAS-8261
> URL: https://issues.jboss.org/browse/JBAS-8261
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: JBossAS-5.1.0.GA
> Environment: OS: Linux (2.6.16.46-0.12-bigsmp)
> JVM: Java HotSpot(TM) Server VM (16.3-b01, mixed mode) (JRE 1.6.0_20)
> Reporter: Bart Berger
> Assignee: David Lloyd
> Fix For: No Release
>
>
> Encountered the following deadlock:
> "Finalizer" daemon prio=8 tid=3 BLOCKED
> at org.jboss.logmanager.LoggerNode.getParentLogger(LoggerNode.java:142)
> Local Variable: org.jboss.logmanager.LoggerNode#362
> at org.jboss.logmanager.LoggerInstance.getParent(LoggerInstance.java:167)
> at org.jboss.logmanager.LoggerInstance.setLevel(LoggerInstance.java:96)
> Local Variable: java.util.logging.Level#2
> Local Variable: org.jboss.logmanager.LogContext#1
> at org.jboss.logmanager.LoggerInstance.finalize(LoggerInstance.java:204)
> at java.lang.ref.Finalizer.$$YJP$$invokeFinalizeMethod(Native Method)
> at java.lang.ref.Finalizer.invokeFinalizeMethod(Finalizer.java)
> at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
> Local Variable: org.jboss.logmanager.LoggerInstance#161
> at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
> Local Variable: java.lang.ref.Finalizer#65597
> "Timer-Log4jService" daemon prio=5 tid=25 WAITING
> at sun.misc.Unsafe.$$YJP$$park(Native Method)
> at sun.misc.Unsafe.park(Unsafe.java)
> Local Variable: sun.misc.Unsafe#1
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> Local Variable: java.util.concurrent.locks.AbstractQueuedSynchronizer$Node#629
> Local Variable: java.util.concurrent.locks.AbstractQueuedSynchronizer$Node#630
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> Local Variable: java.util.concurrent.locks.ReentrantLock$NonfairSync#89
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> Local Variable: java.util.concurrent.locks.ReentrantLock#42
> at org.jboss.logmanager.LoggerInstance.setLevel(LoggerInstance.java:89)
> at org.jboss.logmanager.LoggerInstance.<init>(LoggerInstance.java:53)
> Local Variable: org.jboss.logmanager.LoggerInstance#1049
> Local Variable: java.lang.String#936666
> at org.jboss.logmanager.LoggerNode.getOrCreateLogger(LoggerNode.java:127)
> at org.jboss.logmanager.LogContext.getLogger(LogContext.java:71)
> at org.jboss.logmanager.LogManager.getLogger(LogManager.java:273)
> at java.util.logging.LogManager.demandLogger(LogManager.java:390)
> at java.util.logging.Logger.getLogger(Logger.java:274)
> Local Variable: org.jboss.logmanager.LogManager#1
> at org.jboss.logbridge.LogBridgeHandler.updateLoggers(LogBridgeHandler.java:123)
> Local Variable: java.util.Collections$SynchronizedMap#43
> Local Variable: java.util.Vector$1#3
> Local Variable: org.apache.log4j.spi.RootLogger#1
> Local Variable: org.apache.log4j.Hierarchy#1
> Local Variable: org.apache.log4j.Logger#375
> Local Variable: java.lang.String#582052
> Local Variable: org.jboss.logbridge.LevelMapper#1
> Local Variable: org.jboss.logbridge.LogBridgeHandler#1
> at org.jboss.logbridge.LogNotificationListener.handleNotification(LogNotificationListener.java:67)
> at sun.reflect.GeneratedMethodAccessor203.invoke(<unknown string>)
> Local Variable: sun.reflect.GeneratedMethodAccessor203#1
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> Local Variable: sun.reflect.DelegatingMethodAccessorImpl#458
> at java.lang.reflect.Method.invoke(Method.java:597)
> Local Variable: org.jboss.logbridge.LogNotificationListener#1
> at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
> Local Variable: java.lang.String#2851584
> Local Variable: java.lang.Object[]#760535
> Local Variable: org.jboss.mx.notification.NotificationListenerProxy#2
> Local Variable: java.lang.reflect.Method#16042
> at $Proxy73.handleNotification(<unknown string>)
> at org.jboss.mx.util.JBossNotificationBroadcasterSupport.handleNotification(JBossNotificationBroadcasterSupport.java:127)
> Local Variable: $Proxy73#1
> at org.jboss.mx.util.JBossNotificationBroadcasterSupport.sendNotification(JBossNotificationBroadcasterSupport.java:108)
> Local Variable: org.jboss.mx.notification.DefaultListenerRegistration#3
> Local Variable: org.jboss.mx.notification.ListenerRegistry$ListenerRegistrationIterator#1
> at org.jboss.logging.Log4jService.emitReconfigureNotification(Log4jService.java:560)
> Local Variable: org.jboss.logging.Log4jService#1
> Local Variable: javax.management.Notification#1
> at org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:716)
> at org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:636)
> Local Variable: org.jboss.net.protocol.resource.ResourceURLConnection#1
> at java.util.TimerThread.mainLoop(Timer.java:512)
> Local Variable: java.lang.Object#18446
> Local Variable: org.jboss.logging.Log4jService$URLWatchTimerTask#1
> Local Variable: java.util.TaskQueue#5
> at java.util.TimerThread.run(Timer.java:462)
> The timer thread ran logging configuration while the finalizer was processing LoggerInstance objects.
> The Finalizer thread calls context.levelTreeLock.lock() in LoggerInstance.setLevel(), then enters a synchronized code block in LoggerNode.getParentLogger(). The configuration thread enters a synchronized code block in LoggerNode.getOrCreateLogger(), then creates a new LoggerInstance which calls context.levelTreeLock.lock() in LoggerInstance.setLevel().
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months