I'm very curious! Can't wait to see it. Go for it!
On Sunday, January 26, 2014, Ralph Goers <ralph.go...@dslextreme.com> 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<javascript:_e({}, 'cvml',
> '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<javascript:_e({}, 'cvml', '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<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
