In the constructor each of them calls Levels.addLevel(this). Ralph
On Jan 25, 2014, at 2:21 PM, Remko Popma <[email protected]> wrote: > Interesting! So, users would add custom levels by creating a new enum that > implements the Level interface? How does the new enum get registered? In > config or in code? > > Just trying to understand how it works... > > (With Nick's class I understood how that would work: users would extend the > Level class and pass an instance of that class to the Logger.log() methods; > in config they could specify the new Level name, and the > Level.toLevel(String, Level) method would find the custom instance in a > static HashMap in the Level superclass.) > > On Sunday, January 26, 2014, Ralph Goers <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>>> wrote: >>>>>> On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma <[email protected]> >>>>>> 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 >>>>>>
