You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2017/08/21 21:10:53 UTC

org.apache.logging.log4j.core.LoggerContext getLogger(Class)

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

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

Posted by Ralph Goers <ra...@dslextreme.com>.

“Out of bounds” is not the correct statement. Unnecessary is.  We already convert the class name to a String in the API so there is no reason to have that method.

Ralph

> On Aug 22, 2017, at 8:32 AM, Gary Gregory <ga...@gmail.com> wrote:
> 
> Hi Ralph,
> 
> I looked over the links and I (still) do understand the separation and I
> have a follow up question below.
> 
> First, to be precise, I am proposing to add this shorthand method (note
> there is no @Override to ease compatibility, so no change to
> org.apache.logging.log4j.spi.LoggerContext):
> 
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java
> index cd15dce..8002853 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java
> @@ -410,6 +410,17 @@
>     }
> 
>     /**
> +     * Returns a Logger using the fully qualified name of the Class as the
> Logger name.
> +     *
> +     * @param clazz The Class whose name should be used as the Logger
> name. If null it will default to the calling
> +     *            class.
> +     * @return The Logger.
> +     */
> +    public Logger getLogger(final Class<?> clazz) {
> +        return getLogger(clazz.getCanonicalName(), null);
> +    }
> +
> +    /**
>      * Gets a Logger from the Context.
>      *
>      * @param name The name of the Logger to return.
> 
> Regardless of the above, would you say that the interface
> org.apache.logging.log4j.spi.LoggerContext is also "out of bounds" for
> normal/non-advanced use cases of "get me a logger" even though it is in the
> log4j-api module?
> 
> Thank you again!
> Gary
> 
> 
> On Mon, Aug 21, 2017 at 10:34 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> 
>> On Mon, Aug 21, 2017 at 10:27 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>> 
>>> I would say look at http://logging.apache.org/log4j/2.x/ <
>>> http://logging.apache.org/log4j/2.x/> and that paragraph entitled “API
>>> Separation”. Then look at http://logging.apache.org/log4
>>> j/2.x/manual/api.html <http://logging.apache.org/log
>>> 4j/2.x/manual/api.html>. The first paragraph makes it clear what our
>>> intent is. It should be telling that nowhere on that page is the
>>> LoggerContext mentioned. It isn’t until you get to the Configuration
>>> section that LoggerContext APIs are discussed.
>>> 
>>> So the intent of the design is that code that is performing logging
>>> sticks to the Log4j API - providing it with a guarantee of backward
>>> compatibility. In a lot of cases no custom configuration is needed and so
>>> the whole application will be compatible no matter what we change
>>> internally.  That doesn’t mean that getLogger() cannot be called - but IMO
>>> applications should never be calling it for “normal" logging operations.
>>> 
>>> All of that said, I wouldn’t veto a code commit to do what you want. It
>>> is just not something I’d consider as a worst practice if I found it in
>>> someone’s code for “normal” logging and I would strongly recommend they
>>> change it.
>>> 
>> 
>> Thanks for the details. I'll read up on the links and sleep on it.
>> 
>> Gary
>> 
>> 
>>> 
>>> Ralph
>>> 
>>>> On Aug 21, 2017, at 6:45 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>> 
>>>> 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 <
>>> ralph.goers@dslextreme.com>
>>>> wrote:
>>>> 
>>>>> I am against encouraging users to directly acquire a Logger.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>> 
>>>>>> On Aug 21, 2017, at 5:24 PM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>> On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers <
>>> ralph.goers@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 <ga...@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.goers@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 <garydgregory@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.goers@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 <
>>> garydgregory@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
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>>

Re: org.apache.logging.log4j.core.LoggerContext getLogger(Class)

Posted by Matt Sicker <bo...@gmail.com>.

LoggerContext is included in log4j-api as an SPI class. It's for
implementors, not users.

On 22 August 2017 at 12:22, Gary Gregory <ga...@gmail.com> wrote:

> On Tue, Aug 22, 2017 at 10:27 AM, Remko Popma <re...@gmail.com>
> wrote:
>
> > What I don't like about this proposal is that LogManager.getLogger(Class)
> > would end up working differently than
> > o.a.l.l.core.LoggerContext.getLogger(Class). (One uses Class.getName,
> the
> > other Class.getCanonicalName.)
> >
>
> No it would not, LogManager now uses getCanonicalName() based on last
> week's discussion. The shorthand APIs should all use getCanonicalName()
> now.
>
>
> >
> > Why not just use org.apache.logging.log4j.core.
> > LoggerContext.getLogger(clazz.getCanonicalName()) in your application?
> >
>
> Because that leave open the original problem, it's too easy to mess up and
> call getName().  This is a shorthand API just like
> LogManager.getLogger(Class). I always want to call an API that takes a
> Class where I can to avoid the mix up.
>
> Gary
>
> >
> > On Wed, Aug 23, 2017 at 12:32 AM, Gary Gregory <ga...@gmail.com>
> > wrote:
> >
> > > Hi Ralph,
> > >
> > > I looked over the links and I (still) do understand the separation and
> I
> > > have a follow up question below.
> > >
> > > First, to be precise, I am proposing to add this shorthand method (note
> > > there is no @Override to ease compatibility, so no change to
> > > org.apache.logging.log4j.spi.LoggerContext):
> > >
> > > diff --git
> > > a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> > > LoggerContext.java
> > > b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> > > LoggerContext.java
> > > index cd15dce..8002853 100644
> > > ---
> > > a/log4j-core/src/main/java/org/apache/logging/log4j/core/
> > > LoggerContext.java
> > > +++
> > > b/log4j-core/src/main/java/org/apache/logging/log4j/core/
> > > LoggerContext.java
> > > @@ -410,6 +410,17 @@
> > >      }
> > >
> > >      /**
> > > +     * Returns a Logger using the fully qualified name of the Class as
> > the
> > > Logger name.
> > > +     *
> > > +     * @param clazz The Class whose name should be used as the Logger
> > > name. If null it will default to the calling
> > > +     *            class.
> > > +     * @return The Logger.
> > > +     */
> > > +    public Logger getLogger(final Class<?> clazz) {
> > > +        return getLogger(clazz.getCanonicalName(), null);
> > > +    }
> > > +
> > > +    /**
> > >       * Gets a Logger from the Context.
> > >       *
> > >       * @param name The name of the Logger to return.
> > >
> > > Regardless of the above, would you say that the interface
> > > org.apache.logging.log4j.spi.LoggerContext is also "out of bounds" for
> > > normal/non-advanced use cases of "get me a logger" even though it is in
> > the
> > > log4j-api module?
> > >
> > > Thank you again!
> > > Gary
> > >
> > >
> > > On Mon, Aug 21, 2017 at 10:34 PM, Gary Gregory <garydgregory@gmail.com
> >
> > > wrote:
> > >
> > > > On Mon, Aug 21, 2017 at 10:27 PM, Ralph Goers <
> > > ralph.goers@dslextreme.com>
> > > > wrote:
> > > >
> > > >> I would say look at http://logging.apache.org/log4j/2.x/ <
> > > >> http://logging.apache.org/log4j/2.x/> and that paragraph entitled
> > “API
> > > >> Separation”. Then look at http://logging.apache.org/log4
> > > >> j/2.x/manual/api.html <http://logging.apache.org/log
> > > >> 4j/2.x/manual/api.html>. The first paragraph makes it clear what our
> > > >> intent is. It should be telling that nowhere on that page is the
> > > >> LoggerContext mentioned. It isn’t until you get to the Configuration
> > > >> section that LoggerContext APIs are discussed.
> > > >>
> > > >> So the intent of the design is that code that is performing logging
> > > >> sticks to the Log4j API - providing it with a guarantee of backward
> > > >> compatibility. In a lot of cases no custom configuration is needed
> and
> > > so
> > > >> the whole application will be compatible no matter what we change
> > > >> internally.  That doesn’t mean that getLogger() cannot be called -
> but
> > > IMO
> > > >> applications should never be calling it for “normal" logging
> > operations.
> > > >>
> > > >> All of that said, I wouldn’t veto a code commit to do what you want.
> > It
> > > >> is just not something I’d consider as a worst practice if I found it
> > in
> > > >> someone’s code for “normal” logging and I would strongly recommend
> > they
> > > >> change it.
> > > >>
> > > >
> > > > Thanks for the details. I'll read up on the links and sleep on it.
> > > >
> > > > Gary
> > > >
> > > >
> > > >>
> > > >> Ralph
> > > >>
> > > >> > On Aug 21, 2017, at 6:45 PM, Gary Gregory <garydgregory@gmail.com
> >
> > > >> wrote:
> > > >> >
> > > >> > 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 <
> > > >> ralph.goers@dslextreme.com>
> > > >> > wrote:
> > > >> >
> > > >> >> I am against encouraging users to directly acquire a Logger.
> > > >> >>
> > > >> >> Ralph
> > > >> >>
> > > >> >>
> > > >> >>> On Aug 21, 2017, at 5:24 PM, Gary Gregory <
> garydgregory@gmail.com
> > >
> > > >> >> wrote:
> > > >> >>>
> > > >> >>> On Mon, Aug 21, 2017 at 6:01 PM, Ralph Goers <
> > > >> ralph.goers@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 <
> > garydgregory@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.goers@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 <
> > > garydgregory@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.goers@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 <
> > > >> garydgregory@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 <bo...@gmail.com>