Never mind I see you just committed. :-)
I'll review and provide feedback if necessary.
N
On Jan 26, 2014, at 1:36 PM, Nick Williams wrote:
> 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.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
>>>
>>
>
