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
