So I assume we could build on this by adding the ability to generate these
custom levels from the config, with no user provided class required?
On Jan 26, 2014 12:58 AM, "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
>>
>>
>
