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.go...@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.po...@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 <garydgreg...@gmail.com> wrote:
>> On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma <remko.po...@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 <garydgreg...@gmail.com>
>> wrote:
>> On Thu, Jan 23, 2014 at 10:45 PM, Remko Popma <remko.po...@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 <garydgreg...@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: garydgreg...@gmail.com | ggreg...@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
>
