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

[James Netherton (JIRA)]

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

James Netherton commented on LOGMGR-167:
----------------------------------------

Yes, understood.

For my scenario, the requirement (See ENTESB-7117) is that Camel (loaded via its own module class loader) can utilize WildFly / EAP logging profiles. The fallback on the TCCL would enable this (for this use case at least).

Is there any other way for a subsystem to influence the selected {{LogContext}} (or WildFly / EAP logging in general)? Perhaps via a {{DeploymentUnitProcessor}} or similar?

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