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
