Would it be an option to require that the custom level class package is mentioned in the Configuration packages="..." attribute?
On Sun, Jan 26, 2014 at 9:26 AM, Paul Benedict <pbened...@apache.org> wrote: > If you made it a requirement for the constructor to register, why not just > instantiate each level as you encounter it in the config? > > > On Sat, Jan 25, 2014 at 6:06 PM, Ralph Goers > <ralph.go...@dslextreme.com>wrote: > >> Hmm. It seems I am going to have to do something to force the >> registration as the custom level class hasn’t been constructed before the >> levels are referenced in the configuration. >> >> Ralph >> >> On Jan 25, 2014, at 3:43 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >> In the constructor each of them calls Levels.addLevel(this). >> >> Ralph >> >> On Jan 25, 2014, at 2:21 PM, Remko Popma <remko.po...@gmail.com> 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 <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 >>> >>> >>> >> >> > > > -- > Cheers, > Paul >