[jboss-jira] [JBoss JIRA] (LOGMGR-167) Enable fallback on thread context ClassLoader for log context scanning

[James Perkins (JIRA)]

    [ https://issues.jboss.org/browse/LOGMGR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447515#comment-13447515 ] 

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-321487820



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)