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<javascript:_e({}, 'cvml',
'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
>
