I'd rather we had a log4j-api way to initialise configuration outside the default class initialisation path.
On 21 August 2017 at 19:24, Gary Gregory <garydgreg...@gmail.com> wrote: > On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > It is actually funny that you say that. The API we provide for performing > > logging is log4j-api, not log4j-core. We provide access in log4j-core for > > users to customize how they configure their logging - not perform it. > > > > I'm all about humoring the ML :-) > > Any further thoughts on adding these APIs? For or against? > > Gary > > > > > Ralph > > > > > On Aug 21, 2017, at 3:42 PM, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > > Hi, > > > > > > When someone calls any of the init methods like > > > org.apache.logging.log4j.core.config.Configurator.initialize(String, > > > ClassLoader, String), you get a Core LoggerContext, and that's what > > you've > > > got to work with... Why is that a bad idea? That's the API we provide. > > > > > > Gary > > > > > > On Mon, Aug 21, 2017 at 4:30 PM, Ralph Goers < > ralph.go...@dslextreme.com > > > > > > wrote: > > > > > >> So you are saying that your application is getting Loggers by doing > > >> LoggerContext.getLogger()? I guess I don’t really understand why that > > is a > > >> good idea. Are you saying you have your own custom LoggerContext and > > that > > >> you want to modify Log4j’s LoggerContext simply so you can modify > yours? > > >> > > >> Ralph > > >> > > >>> On Aug 21, 2017, at 3:01 PM, Gary Gregory <garydgreg...@gmail.com> > > >> wrote: > > >>> > > >>> My use case is that deep in the guts and call stack of my > server/app, I > > >>> have a specific Core LoggerContext that I should/must use. Log4j and > > >> other > > >>> components must co-exist in a long-lived server that have modules > that > > >> are > > >>> constantly re-initialized/re-configured during development and > testing > > >>> phases. During acceptance and production, the are fewer > > reconfigurations, > > >>> but they do happen. The bottom line is that most logging code dishes > > out > > >>> Loggers out of specific LoggerContext instances and not out of the > > >>> LogManager classes (only in a few rare places.) > > >>> > > >>> Gary > > >>> > > >>> On Mon, Aug 21, 2017 at 3:47 PM, Ralph Goers < > > ralph.go...@dslextreme.com > > >>> > > >>> wrote: > > >>> > > >>>> Did you ask this question last week? Why is it needed? Why can’t > this > > >> be > > >>>> handled in LogManager? > > >>>> > > >>>> Ralph > > >>>> > > >>>>> On Aug 21, 2017, at 2:10 PM, Gary Gregory <garydgreg...@gmail.com> > > >>>> wrote: > > >>>>> > > >>>>> Hi All: > > >>>>> > > >>>>> I have a need for the shortcut method > > >>>>> org.apache.logging.log4j.core.LoggerContext getLogger(Class) which > > >> would > > >>>>> use getCannonicalName(). > > >>>>> > > >>>>> Any objection to adding that? > > >>>>> > > >>>>> Gary > > >>>> > > >>>> > > >>>> > > >> > > >> > > >> > > > > > > > -- Matt Sicker <boa...@gmail.com>
