Actually, we can use switch in all the places it is currently being used. They
are all places where we are converting between our levels to a Level or
Severity from some other framework. I handled that by first mapping custom
levels to the closest standard level and then using the switch statement as we
always had.
FWIW, I think I found a way to continue to keep the standard levels as an enum
while using Nick’s approach. Still working on it.
Ralph
On Jan 25, 2014, at 6:26 PM, Paul Benedict <pbened...@apache.org> wrote:
> You can't "switch" anymore because custom levels means you're dealing with an
> unknown quantity of levels. You'll have to look them up in a registry/map.
> That's the trade off of an extensible system.
>
> On Jan 25, 2014 8:13 PM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote:
> Rats. StdLevel isn’t a Level because it can’t extend it if it is an enum, so
> I can’t initialize the levels using that. So no switch statements if we go
> this way. I’ll keep looking at it but that makes this solution less
> appealing to me.
>
> Ralph
>
> On Jan 25, 2014, at 6:05 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
>> Sure, I can take a look at doing it that way. But it is going to have many
>> of the same problems to implement as to what I just finished doing - except
>> that I won’t need the Levels class or Levels interface. The one downside to
>> this approach is that there are 4 or 5 places where Level is used in a
>> switch statement and that won’t be possible any more so all of those will
>> have to be converted to if, else if, else clauses on the “standard” levels.
>> The extended levels will have the same problem being located by the
>> configuration so I can reuse the same solution.
>>
>> Otoh, if Level is an abstract Class as you have done I can still keep
>> StdLevels as an enum so that it can be used in switch statements as I am
>> currently doing but then reference them as static members of the Level class
>> (as I currently do in the Interface). In that case the change might be a bit
>> simpler and, as you note, extending it would be fairly simple.
>>
>> Ralph
>>
>> On Jan 25, 2014, at 5: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
>>>>>>>>> JUnit in Action, Second Edition
>>>>>>>>> Spring Batch in Action
>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
