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
>
>
