logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Enums and Custom Levels
Date Sun, 26 Jan 2014 02:51:45 GMT
I've started to think about how to implement Gary's idea to use these
custom levels to generate code that would add methods to the Logger
interface, but I think I'll wait a little to see what form the custom
levels take.


On Sun, Jan 26, 2014 at 11:45 AM, Remko Popma <remko.popma@gmail.com> wrote:

> These are the switches I found:
> * log4j-1.2-api: org.apache.log4j.Category - just FYI, it looks like this
> switch is missing the FATAL level... is this a bug?
> * log4j-api: org.apache.logging.log4j.status.StatusLogger
> * log4j-core: org.apache.logging.log4j.core.net.Severity
> * log4j-core: org.apache.logging.log4j.core.pattern.LevelPatternConverter
> - perhaps just return "level " + level.toString(); ?
> * log4j-to-slf4j: org.apache.logging.slf4j.SLF4JLogger
>
>
>
> On Sun, Jan 26, 2014 at 11:41 AM, Ralph Goers <ralph.goers@dslextreme.com>wrote:
>
>> I am not sure what you mean by this.  I have already succeeded in adding
>> custom level names to the configuration and making them be valid.  I am
>> just trying to clean it up a bit based on what Nick is suggesting.
>>
>> Ralph
>>
>> On Jan 25, 2014, at 6:30 PM, Scott Deboy <scott.deboy@gmail.com> wrote:
>>
>> There's no way to add support for users to define level entries (name and
>> value pairs as a new element in the config) and have us do the work to make
>> those valid? That would get get rid of my request for additional levels,
>> right?
>> On Jan 25, 2014 6:15 PM, "Ralph Goers" <ralph.goers@dslextreme.com>
>> wrote:
>>
>>> The class is needed because it is a name and a value (two items) that
>>> has to be represented as a single parameter to Logger methods.  Using raw
>>> int or String is not a good alternative.
>>>
>>> Ralph
>>>
>>> On Jan 25, 2014, at 4:54 PM, Scott Deboy <scott.deboy@gmail.com> wrote:
>>>
>>> If levels are just a name and a value why require a class at all? What
>>> about just having it defined in the configuration.
>>> On Jan 25, 2014 4:37 PM, "Ralph Goers" <ralph.goers@dslextreme.com>
>>> wrote:
>>>
>>>> Because we don’t know the class name that the Level belongs to.  It is
>>>> referenced in the configuration just as “DIAG”, not
>>>> “org.apache.logging.test.ExtendedLevel.DIAG”.
>>>>
>>>> In any case I fixed it.  I just annotated the new Level as a Plugin and
>>>> then look up all the Level plugins in BaseConfiguration. Simply calling the
>>>> getEnumConstants method on each of the classes does the trick.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>> On Jan 25, 2014, at 4:26 PM, Paul Benedict <pbenedict@apache.org>
>>>> wrote:
>>>>
>>>> If you made it a requirement for the constructor to register, why not
>>>> just instantiate each level as you encounter it in the config?
>>>>
>>>>
>>>> On Sat, Jan 25, 2014 at 6:06 PM, Ralph Goers <
>>>> ralph.goers@dslextreme.com> wrote:
>>>>
>>>>> Hmm. It seems I am going to have to do something to force the
>>>>> registration as the custom level class hasn’t been constructed before
the
>>>>> levels are referenced in the configuration.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Jan 25, 2014, at 3:43 PM, Ralph Goers <ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> In the constructor each of them calls Levels.addLevel(this).
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Jan 25, 2014, at 2:21 PM, Remko Popma <remko.popma@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Interesting! So, users would add custom levels by creating a new enum
>>>>> that implements the Level interface? How does the new enum get registered?
>>>>> In config or in code?
>>>>>
>>>>> Just trying to understand how it works...
>>>>>
>>>>> (With Nick's class I understood how that would work: users would
>>>>> extend the Level class and pass an instance of that class to the
>>>>> Logger.log() methods; in config they could specify the new Level name,
and
>>>>> the Level.toLevel(String, Level) method would find the custom instance
in a
>>>>> static HashMap in the Level superclass.)
>>>>>
>>>>> On Sunday, January 26, 2014, Ralph Goers <ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> Here is what I am implementing:
>>>>>>
>>>>>> 1. Level is now an Interface.  This allows the vast amount of code
to
>>>>>> continue to work.
>>>>>> 2. The current Level enum has been renamed to StdLevel. It implements
>>>>>> the Level interface.
>>>>>> 3. A new class named Levels is in the spi package of the API. It
>>>>>> contains a ConcurrentMap containing all the registered Levels as
well as
>>>>>> the static methods that were previously part of the Level enum.
>>>>>>
>>>>>> For the most part the conversion to this has been pretty easy.  The
>>>>>> most frustrating part was that I had to move the toLevel methods
from what
>>>>>> was the Level enum to the Levels class as static methods are not
allowed in
>>>>>> interfaces until Java 8. This meant I had to modify several classes
to use
>>>>>> Levels.toLevel instead of Level.toLevel.  In addition, a few classes
were
>>>>>> using the valueOf enum method. Those were converted to use Levels.getLevel.
>>>>>>
>>>>>> The few places were Level is actually used as an enum were also
>>>>>> pretty easy to handle as in those cases the custom levels need to
be
>>>>>> converted to a StdLevel and then that enum is used.
>>>>>>
>>>>>> Unless anyone objects I plan on committing this later today once
I
>>>>>> finish it and create some tests and documentation.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jan 25, 2014, at 12:49 PM, Nicholas Williams <
>>>>>> nicholas@nicholaswilliams.net> wrote:
>>>>>>
>>>>>> No, of course, everyone seems to agree that custom levels should
be
>>>>>> permitted. But I never heard agreement on whether we were going the
>>>>>> extensible enum route or the Level-as-interface route. The camp still
>>>>>> seemed to disagree on that.
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>> Sent from my iPhone, so please forgive brief replies and frequent
>>>>>> typos
>>>>>>
>>>>>> On Jan 25, 2014, at 11:20, Ralph Goers <ralph.goers@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> I have not heard anyone disagree with allowing custom Levels.  The
>>>>>> disagreement I am hearing is over adding new pre-defined levels.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jan 25, 2014, at 7:29 AM, Nick Williams <
>>>>>> nicholas@nicholaswilliams.net> wrote:
>>>>>>
>>>>>> I may have missed something. Did we decide on an approach? Last I
>>>>>> heard, the camp was still split: Some wanted to go with my extensible
enum,
>>>>>> others wanted to change Level to an interface and make a Levels enum.
>>>>>>
>>>>>> So I'm a bit confused. Which implementation are you working on?
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>> On Jan 25, 2014, at 7:08 AM, Ralph Goers wrote:
>>>>>>
>>>>>> I am working on the implementation of custom levels now.  I should
>>>>>> have it done today.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jan 24, 2014, at 7:07 PM, Remko Popma <remko.popma@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> What is the best way to make progress on the custom levels
>>>>>> implementation?
>>>>>>
>>>>>> Do we re-open LOG4J-41 or start a fresh Jira ticket? For
>>>>>> implementation ideas, do we attach files to Jira, or create a branch?
>>>>>>
>>>>>> Remko
>>>>>>
>>>>>> On Saturday, January 25, 2014, Gary Gregory <garydgregory@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma <remko.popma@gmail.com>wrote:
>>>>>>
>>>>>> Gary,
>>>>>>
>>>>>> The hard-coded levels were proposed because it seemed that the
>>>>>> extensible enum idea raised by Nick was not going to be accepted.
>>>>>> My original position was that Markers could fulfill the requirement
>>>>>> but Nick and yourself made it clear that this was not satisfactory.
>>>>>>
>>>>>> With extensible enums and markers off the table it seemed that the
>>>>>> hard-coded levels was the only alternative, and discussion ensued
about
>>>>>> what these levels should be called and what strength they should
have.
>>>>>>
>>>>>> During this discussion, several people, including me, repeatedly
>>>>>> expressed strong reservations about adding pre-defined levels, but
by this
>>>>>> time I think people were thinking there was no alternative.
>>>>>>
>>>>>> It looked like we were getting stuck, with half the group moving
in
>>>>>> one direction ("add pre-defined levels!") and the other half wanting
to
>>>>>> move in another direction ("don't add pre-defined levels!"). I asked
that
>>>>>> we re-reviewed our assumptions and try to reach a solution that would
>>>>>> satisfy all users.
>>>>>>
>>>>>> We then decided to explore the option of using extensible enums
>>>>>> again. This is still ongoing, but I haven't seen anyone arguing against
>>>>>> this idea since we started this thread.
>>>>>>
>>>>>> Hard-coded levels and the extensible enum are different solutions
to
>>>>>> the same problem.
>>>>>>
>>>>>>
>>>>>> Hello All:
>>>>>>
>>>>>> Absolutely not. See my DEFCON example.
>>>>>> Talking about an "extensible enum" is mixing design and
>>>>>> implementation, we are talking about 'custom' and/or 'extensible'
levels.
>>>>>> Custom/Extensible levels can be designed to serve one or all of:
>>>>>>
>>>>>> - Allow inserting custom levels between built-in levels.
>>>>>> - Allow for domain specific levels outside of the concept of built-in
>>>>>> levels, the DEFCON example.
>>>>>> - Should the custom levels themselves be extensible?
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>>
>>>
>>
>

Mime
View raw message