logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Williams <nicho...@nicholaswilliams.net>
Subject Re: Enums and Custom Levels
Date Sun, 26 Jan 2014 01:32:05 GMT
I actually do object I think. It sounds like a significantly more convoluted approach than
the extensible enum. With the extensible enum, new levels are immediately discovered, serialization
works automatically, and extenders don't have to do any extra work in the constructor. Why
are we making this so difficult?

Nick

Sent from my iPhone, so please forgive brief replies and frequent typos

> On Jan 25, 2014, at 15:18, 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
>>>>>>>  
>>>>>>> The extensible enum solution satisfies all of us who are opposed
to adding pre-defined levels, while also satisfying the original requirement raised by Nick
and yourself. Frankly I don't understand why you would still want the pre-defined levels.
>>>>>>> 
>>>>>>> Remko
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Sat, Jan 25, 2014 at 12:53 AM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>>>> On Thu, Jan 23, 2014 at 10:45 PM, Remko Popma <remko.popma@gmail.com>
wrote:
>>>>>>> Gary, 
>>>>>>> 
>>>>>>> I think that's a very cool idea!
>>>>>>> Much more flexible, powerful and elegant than pre-defined levels
could ever be. 
>>>>>>> 
>>>>>>> As I wrote: "I am discussing custom levels here with the understanding
that this is a separate topic from what the built-in levels are."
>>>>>>> 
>>>>>>> I'm not sure why you want to make the features mutually exclusive.
(Some) others agree that these are different features.
>>>>>>> 
>>>>>>> I see two topics:
>>>>>>> 
>>>>>>> - What are the default levels for a 21st century logging framework.
Do we simply blindly copy Log4j 1? Or do we look at frameworks from different languages and
platforms for inspiration?
>>>>>>> - How (not if, I think we all agree) should we allow for custom
levels.
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> It definitely makes sense to design the extensible enum with
this potential usage in mind. 
>>>>>>> 
>>>>>>> Remko
>>>>>>> 
>>>>>>> 
>>>>>>> On Friday, January 24, 2014, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>>>>> I am discussing custom levels here with the understanding that
this is a separate topic from what the built-in levels are. Here is how I convinced myself
that custom levels are a “good thing”.
>>>>>>> 
>>>>>>> No matter which built-in levels exits, I may want custom levels.
For example, I want my app to use the following levels DEFCON1, DEFCON2, DEFCON3, DEFCON4,
and DEFCON5. This might be for one part of my app or a whole subsystem, no matter, I want
to use the built-in levels in addition to the DEFCON levels. It is worth mentioning that if
I want that feature only as a user, I can “skin” levels in a layout and assign any label
to the built-in levels. If I am also a developer, I want to use DEFCON levels in the source
code.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> At first, my code might look like:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> logger.log(DefconLevels.DEFCON5, “All is quiet”);
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Let’s put aside for now the type of DefconLevels.DEFCON* objects.
I am a user, and I care about my call sites.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> What I really want of course is to write:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> defconLogger.defcon5(“All is quiet”)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Therefore, I argue that for any “serious” use of a custom
level, I will wrap a Logger in a custom logger class providing call-site friendly methods
like defcon5(String).
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> So now, as a developer, all I care about is DefConLogger. It
might wrap (or subclass) the Log4J Logger, who knows. The implementation of DefConLogger is
not important to the developer (all I care is that the class has ‘defconN’ method) but
it is important to the configuration author. This tells me that as a developer I do not care
how DefConLogger is implemented, with custom levels, markers, or elves. However, as configuration
author, I also want to use DEFCON level just like the built-in levels.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> The configuration code co
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> JUnit in Action, Second Edition
>>>>>>> Spring Batch in Action
>>>>>>> Blog: http://garygregory.wordpress.com 
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
> 

Mime
View raw message