I’ve committed the changes. Take a look at ExtendedLevels.java,
ExtendedLevelTest.java and log4j-customLevel.xml in the log4j-core test
directories to see how it works.
Ralph
On Jan 26, 2014, at 1:19 AM, Remko Popma <remko.po...@gmail.com> wrote:
> 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> 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
>>
>
