ppkarwasz commented on issue #3357: URL: https://github.com/apache/logging-log4j2/issues/3357#issuecomment-2589148313
> We have an application with plugins where plugin are added/removed dynamically. For for this plugins we use `ModuleLayer`s. So, we have the following layer configuration: > > ``` > boot layer / main app > ├── child layer 1 / plugin foo > │ ├── moduleA > │ ├── moduleC > │ └── moduleX > ├── child layer 2 / plugin bar > │ ├── moduleS > │ ├── moduleV > │ └── moduleX > └ > etc > ``` > > As you see, in this configuration the same module is used by both plugins. So, when we want to get messages of the `moduleX` we definitely want to get them for getting messages of concrete plugin. That's why I say it is important to get not only module name, but also some ID of the layer. This architecture resembles a lot the one used in Servlet containers. To be able to effectively determine, which plugin is currently running, you could use some of the solutions used in Servlet containers. Some of the possibilities: 1. Each time control is transferred to one of the plugins, you could bind a value to the current thread. For example you could use [`ThreadContext`](https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/ThreadContext.html) to do it. We do something similar in [`Log4jServletFilter`](https://github.com/apache/logging-log4j2/blob/2.x/log4j-web/src/main/java/org/apache/logging/log4j/web/Log4jServletFilter.java), where we bind the logger context associated to the web application to the current thread. 2. You could also use the approach used by Tomcat: Tomcat uses a custom classloader for each application that implements [`WebappProperties`](https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/juli/WebappProperties.html). When control is passed to an application the web application classloader is set as thread context classloader and can be retrieved by custom Log4j plugins. In [my personal Log4j extensions](https://github.com/copernik-eu/log4j-tomcat/tree/main/log4j-tomcat/src/main/java/eu/copernik/log4j/tomcat) I used this fact to implement a [`ContextDataProvider`](https://github.com/copernik-eu/log4j-tomcat/tree/main/log4j-tomcat/src/main/java/eu/copernik/log4j/tomcat), a [lookup](https://logging.apache.org/log4j/2.x/manual/lookups.html) and a [`ContextSelector`](https://logging.apache.org/log4j/2.x/manual/extending.html#ContextSelector). 3. You could use JNDI to retrieve the service name, although that is an endless source of security bugs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
