[jboss-jira] [JBoss JIRA] (LOGMGR-167) Enable fallback on thread context ClassLoader for log context scanning
[
https://issues.jboss.org/browse/LOGMGR-167?page=com.atlassian.jira.plugin...
]
James Perkins commented on LOGMGR-167:
--------------------------------------
There is a {{ContextClassLoaderLogContextSelector}} in jboss-logmanager already. However
WildFly uses it's own
[{{LogContextSelector}}|https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java/org/jboss/as/logging/logmanager/WildFlyLogContextSelectorImpl.java].
Registering the {{LogContext}} on WildFly is happening during the deployment processing.
Nothing in the deployment itself should be invoked until deployment processing is complete
so in theory there shouldn't be a race condition.
Are the Spring dependencies included in the deployment or are they installed as a module?
Enable fallback on thread context ClassLoader for log context
scanning
----------------------------------------------------------------------
Key: LOGMGR-167
URL: https://issues.jboss.org/browse/LOGMGR-167
Project: JBoss Log Manager
Issue Type: Enhancement
Reporter: James Netherton
{{ClassLoaderLogContextSelector}} searches the call stack for a {{ClassLoader}}
that's used as a map key to discover the appropriate {{LogContext}}.
If the search fails, can we add an additional check that uses the
ThreadContextClassLoader to lookup the {{LogContext}} from the {{contextMap}}?
My reasoning for requesting this is described in this issue:
https://github.com/wildfly-extras/wildfly-camel/issues/1919#issuecomment-...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)