Hi Ralph, Would you say that is your opinion or the intent of the design? And if the latter, should we adjust the Javadoc accordingly.
Gary On Mon, Aug 21, 2017 at 7:31 PM, Ralph Goers <[email protected]> wrote: > I am against encouraging users to directly acquire a Logger. > > Ralph > > > > On Aug 21, 2017, at 5:24 PM, 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 > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > >> > >> > >> > > >
