That sounds like a pretty good idea.
Matt Sicker
> On Jan 25, 2014, at 15:18, Ralph Goers <ralph.go...@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
>> <nicho...@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.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
>
