logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Williams <nicho...@nicholaswilliams.net>
Subject Re: Enums and Custom Levels - completed.
Date Sun, 26 Jan 2014 19:36:53 GMT
Can you post a diff or the related files somewhere? Obviously it can be tweaked after commit
if necessary, but I'd like to see if there's anything major that sticks out to me before you
commit.

Thanks,

Nick

On Jan 26, 2014, at 2:57 AM, Ralph Goers wrote:

> I have completed the work on custom levels.  It uses a variation of Nick’s “extensible
enum” class.  The major difference with what he proposed is that the custom enums must be
declared in a class annotated with @Plugin(name=“xxxx” category=“Level”) for them
to be usable during configuration.
> 
> Are their any objections to me checking this in?  I’ll be doing the commit at around
noon Pacific Daylight Time if I don’t hear any.
> 
> Ralph
> 
> 
> 
> On Jan 25, 2014, at 7:08 AM, Ralph Goers <Ralph.Goers@dslextreme.com> 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