Hi Ralph,
On Tue, 7 Jun 2022 at 22:31, Ralph Goers wrote:
> You do not want to point the external context to JUnit’s ExtensionContext.
> Instead,
> you should add it as a key to the externalMap.
Why is that? Does `getExternalContext` have a special meaning or is it obsolete?
I don't fully unde
Hi all,
On Tue, 7 Jun 2022 at 20:22, Matt Sicker wrote:
> For the record, I like Piotr's idea on repurposing this parameter to
> allow for better caching of LoggerContext in the anchor spot. This
> should help with some test parallelization efforts we're working on.
I believe this can help in mo
I would think we would want to use some sort of JunitContextSelector and modify
PropertiesUtil so that JUnit can provide the SystemProperties.
You do not want to point the external context to JUnit’s ExtensionContext.
Instead,
you should add it as a key to the externalMap.
Ralph
> On Jun 7, 2
Hi Volcan,
On Tue, 7 Jun 2022 at 21:04, Volkan Yazıcı wrote:
> Piotr, thanks so much for sparing time for test parallelization. Is there
> anything else we can do rather than thread-local `LoggerContext`s? Can't we
> configure a `ContextSelector` for tests such that it will attach the
> `LoggerCo
While working on test parallelisation, I was looking for the existent
> mechanisms to bind a logger context to a thread. That is easily
> provided by `ContextAnchor.THREAD_CONTEXT` which can be accessed by
> `LogManager.getContext()/LogManager.getContext(true)`.
>
> However I
> While working on test parallelisation, I was looking for the existent
> mechanisms to bind a logger context to a thread. That is easily
> provided by `ContextAnchor.THREAD_CONTEXT` which can be accessed by
> `LogManager.getContext()/LogManager.getContext(true)`.
>
> However I am no
Hi all,
While working on test parallelisation, I was looking for the existent
mechanisms to bind a logger context to a thread. That is easily
provided by `ContextAnchor.THREAD_CONTEXT` which can be accessed by
`LogManager.getContext()/LogManager.getContext(true)`.
However I am not sure what is
