Nick, I think because your solution is considered "old style" enums. I
don't know anyone making those kind of enums anymore since JDK 1.5 gave us
an official "enum" keyword. Using that and interfaces is preferred, I think.
On Sat, Jan 25, 2014 at 7:32 PM, Nicholas Williams <
nicho...@nicholaswilliams.net> wrote:
> I actually do object I think. It sounds like a significantly more
> convoluted approach than the extensible enum. With the extensible enum, new
> levels are immediately discovered, serialization works automatically, and
> extenders don't have to do any extra work in the constructor. Why are we
> making this so difficult?
>
> Nick
>
> Sent from my iPhone, so please forgive brief replies and frequent typos
>
> On Jan 25, 2014, at 15:18, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
> Here is what I am implementing:
>
> 1. Level is now an Interface. This allows the vast amount of code to
> continue to work.
> 2. The current Level enum has been renamed to StdLevel. It implements the
> Level interface.
> 3. A new class named Levels is in the spi package of the API. It contains
> a ConcurrentMap containing all the registered Levels as well as the static
> methods that were previously part of the Level enum.
>
> For the most part the conversion to this has been pretty easy. The most
> frustrating part was that I had to move the toLevel methods from what was
> the Level enum to the Levels class as static methods are not allowed in
> interfaces until Java 8. This meant I had to modify several classes to use
> Levels.toLevel instead of Level.toLevel. In addition, a few classes were
> using the valueOf enum method. Those were converted to use Levels.getLevel.
>
> The few places were Level is actually used as an enum were also pretty
> easy to handle as in those cases the custom levels need to be converted to
> a StdLevel and then that enum is used.
>
> Unless anyone objects I plan on committing this later today once I finish
> it and create some tests and documentation.
>
> Ralph
>
>
>
> On Jan 25, 2014, at 12:49 PM, Nicholas Williams <
> nicho...@nicholaswilliams.net> wrote:
>
> No, of course, everyone seems to agree that custom levels should be
> permitted. But I never heard agreement on whether we were going the
> extensible enum route or the Level-as-interface route. The camp still
> seemed to disagree on that.
>
> Nick
>
> Sent from my iPhone, so please forgive brief replies and frequent typos
>
> On Jan 25, 2014, at 11:20, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
> I have not heard anyone disagree with allowing custom Levels. The
> disagreement I am hearing is over adding new pre-defined levels.
>
> Ralph
>
> On Jan 25, 2014, at 7:29 AM, Nick Williams <nicho...@nicholaswilliams.net>
> wrote:
>
> I may have missed something. Did we decide on an approach? Last I heard,
> the camp was still split: Some wanted to go with my extensible enum, others
> wanted to change Level to an interface and make a Levels enum.
>
> So I'm a bit confused. Which implementation are you working on?
>
> Nick
>
> On Jan 25, 2014, at 7:08 AM, Ralph Goers 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<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
>>
>
>
>
>
>
--
Cheers,
Paul
