That is a much bigger topic than the one core API I am talking about. Gary
On Aug 21, 2017 18:35, "Matt Sicker" <[email protected]> wrote: > 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 <[email protected]> wrote: > > > On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers <[email protected] > > > > 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 <[email protected]> > > > 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 < > > [email protected] > > > > > > > > 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 <[email protected]> > > > >> 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 < > > > [email protected] > > > >>> > > > >>> 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 < > [email protected]> > > > >>>> 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 <[email protected]> >
