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.go...@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 <nicho...@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.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
>
