logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Enums and Custom Levels - completed.
Date Sun, 26 Jan 2014 08:57:40 GMT
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