“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 <garydgreg...@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 <garydgreg...@gmail.com>
> wrote:
>
>> On Mon, Aug 21, 2017 at 10:27 PM, Ralph Goers <ralph.go...@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 <garydgreg...@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.go...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> I am against encouraging users to directly acquire a Logger.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>> On Aug 21, 2017, at 5:24 PM, 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
