My reading of the javadoc for Thread indicates the do by default. Ralph
On Apr 23, 2019, at 10:12 PM, Benjamin Jaton <benjamin.ja...@gmail.com> wrote: >> If you want all the threads in a “job” then I would create the parent > thread with its own thread group and use the thread group name in the > lookup. > > But how do I assign the thread group to threads that 3rd party libraries > create? I don't think child threads naturally inherit the ThreadGroup of > their parents. > > On Tue, Apr 23, 2019 at 8:36 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> I think the solution is pretty simple. The RoutingAppender doesn’t only >> work with the ThreadContext. It works using a lookup. So if you were to use >> a ThreadLookup that used ${{thread:id}} you would get a new Appender for >> each thread id. To be honest, I am not sure why we haven’t created a >> ThreadLookup before. I could easily see multiple places were the thread id, >> name, priority or ThreadGroup name might want to be used. >> >> If you want all the threads in a “job” then I would create the parent >> thread with its own thread group and use the thread group name in the >> lookup. >> >> Ralph >> >>> On Apr 23, 2019, at 5:06 PM, Benjamin Jaton <benjamin.ja...@gmail.com> >> wrote: >>> >>> Hello, >>> >>> Several times I've been in a situation where in a given JVM I am trying >> to >>> run distinct jobs in separate threads, who themselves might spawn their >> own >>> threads. >>> In those situations I usually want the logging of each job in a separate >>> log file, and that has proven to be difficult. >>> >>> Log4j2 has a routing appender that allows to create a separate appender >> for >>> each job given that you can provide a routing key that's unique for each >>> job. But what key to use for this? >>> I've been using a ThreadContext variable that I set at the level of the >> job >>> thread, and any child thread that I have control over. >>> >>> But the problem is that I don't always have control over this. Sometimes >>> third party APIs let you feed a custom ThreadFactory, sometimes they >> don't. >>> When they don't, I can't set that ThreadContext variable and part of the >>> job logging will be misrouted to a different appender. >>> >>> Is there a way to work around this so that there is 1 log file for each >> job >>> that would gather all the logging of the sub threads? >>> >>> Thanks, >>> Benjamin >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-user-h...@logging.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org