You don’t. Each LoggerContext has its own hierarchy of Loggers. You would set
the log level on the LoggerContext’s root Logger.
Ralph
> On Apr 29, 2019, at 12:18 PM, Benjamin Jaton <benjamin.ja...@gmail.com> wrote:
>
> Yes I've explored that route a little bit, inspired by the existing
> ClassLoaderContextSelector implementation.
>
> One thing I'm not sure about is how do you "set" the log level on a whole
> LoggerContext?
>
> On Mon, Apr 29, 2019 at 12:03 PM Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
>> If you created a ThreadGroupContextSelector it probably would perform
>> better, but you might be trading one set of problems for another.
>>
>> Ralph
>>
>>> On Apr 29, 2019, at 11:58 AM, Benjamin Jaton <benjamin.ja...@gmail.com>
>> wrote:
>>>
>>> I ended up making a DynamicThreadholdFilter to be able to resolve the log
>>> level dynamically.
>>>
>>> What's not so great is that this management of the log level with a
>> "post"
>>> filter requires the logger to let everything through (TRACE).
>>> So then methods like isDebugEnabled() will always return true.
>>>
>>> Anyways for my use case we'll have to go with this as we need a log level
>>> per job (threadgroup).
>>>
>>> On Mon, Apr 29, 2019 at 11:43 AM Matt Sicker <boa...@gmail.com> wrote:
>>>
>>>> Requiring the use of ThreadContext data everywhere can slow things
>>>> down a little, though not sure by how much.
>>>>
>>>> On Thu, 25 Apr 2019 at 13:35, Benjamin Jaton <benjamin.ja...@gmail.com>
>>>> wrote:
>>>>>
>>>>> I've used ThresholdFilter to have the log level check at the level of
>> the
>>>>> (sub) appender:
>>>>>
>>>>> "ThresholdFilter": {
>>>>> "level": "${my:threadgroup.jobLogLevel}",
>>>>> "onMatch": "ACCEPT",
>>>>> "onMismatch": "DENY"
>>>>> }
>>>>>
>>>>> Of course then I need to have the root logger in TRACE to let
>> everything
>>>> in
>>>>> to be filtered later on by the appender:
>>>>>
>>>>> "loggers": {
>>>>> "root": {
>>>>> "level": "TRACE",
>>>>> "additivity": "false",
>>>>> "includeLocation": "true",
>>>>> "AppenderRef": {
>>>>> "ref": "JobsRoutingAppender"
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> What do you think of this?
>>>>> Is performance a concern with this approach?
>>>>>
>>>>> On Thu, Apr 25, 2019 at 9:33 AM Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> Another possibility would be to have a ThreadGroupContextSelector and
>>>> then
>>>>>> use a different LoggerContext and configuration for each ThreadGroup.
>>>>>> However, that could get very complicated. The RoutingAppender pretty
>>>> much
>>>>>> accomplishes the same thing and would be much easier to do.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Apr 25, 2019, at 9:21 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>
>>>>>>> Oh damn, right, bit of a limitation there. I'll ponder on this a bit.
>>>>>>>
>>>>>>> On Thu, 25 Apr 2019 at 11:18, Ralph Goers <
>>>> ralph.go...@dslextreme.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Matt, Benjamin’s issue is that he has no control over what is
>>>> running
>>>>>> in the “jobs” but he wants all the logs for a “job” to end up in the
>>>> same
>>>>>> appender. His definition of a job is that he is creating a thread to
>>>> run it
>>>>>> and everything under that thread should route to that Appender. So he
>>>>>> cannot control what logger names are used much less whether they have
>>>>>> Markers or not.
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Apr 25, 2019, at 8:59 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, 24 Apr 2019 at 18:47, Benjamin Jaton <
>>>> benjamin.ja...@gmail.com>
>>>>>> wrote:
>>>>>>>>>> I've implemented the solution based on ThreadGroups. Now I am
>>>> trying
>>>>>> to
>>>>>>>>>> have a separate log level per job. The goal is to be able to set
>>>> one
>>>>>> job in
>>>>>>>>>> DEBUG or TRACE while the others stay in WARN. Possible?
>>>>>>>>>> The RoutingAppender creates an appender per route but as far as I
>>>>>> know I
>>>>>>>>>> cannot set a log level on the appender object. I guess filters
>>>> could
>>>>>> be
>>>>>>>>>> used but is there something simpler I'm missing?
>>>>>>>>>
>>>>>>>>> I think you'd be better off using markers for that. See
>>>>>>>>> https://logging.apache.org/log4j/2.x/manual/markers.html
>>>>>>>>>
>>>>>>>>> You might also be able to just use a naming scheme for your loggers
>>>>>>>>> that automatically makes them separately configurable as typical
>>>>>>>>> loggers. For example, say you use a naming scheme
>>>>>>>>> "com.example.threadgroup.<groupName>" as your loggers. Then you
>>>> could
>>>>>>>>> configure them by name as usual.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boa...@gmail.com>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
