I mean, not sure whether to use Proxy or generate code or something else, but hopefully get really close to the ease-of-use of the current Logger interface...
On Sun, Jan 26, 2014 at 12:06 PM, Remko Popma <[email protected]> wrote: > I'm not sure how close we can get to what we have now, but yes, that was > what I had in mind... > > > On Sun, Jan 26, 2014 at 12:00 PM, Ralph Goers > <[email protected]>wrote: > >> Wow - I had never thought about using a Java Proxy to implement all those >> methods before. That would be a piece of cake. >> >> Ralph >> >> On Jan 25, 2014, at 6:51 PM, Remko Popma <[email protected]> wrote: >> >> I've started to think about how to implement Gary's idea to use these >> custom levels to generate code that would add methods to the Logger >> interface, but I think I'll wait a little to see what form the custom >> levels take. >> >> >> On Sun, Jan 26, 2014 at 11:45 AM, Remko Popma <[email protected]>wrote: >> >>> These are the switches I found: >>> * log4j-1.2-api: org.apache.log4j.Category - just FYI, it looks like >>> this switch is missing the FATAL level... is this a bug? >>> * log4j-api: org.apache.logging.log4j.status.StatusLogger >>> * log4j-core: org.apache.logging.log4j.core.net.Severity >>> * log4j-core: >>> org.apache.logging.log4j.core.pattern.LevelPatternConverter - perhaps just >>> return "level " + level.toString(); ? >>> * log4j-to-slf4j: org.apache.logging.slf4j.SLF4JLogger >>> >>> >>> >>> On Sun, Jan 26, 2014 at 11:41 AM, Ralph Goers < >>> [email protected]> wrote: >>> >>>> I am not sure what you mean by this. I have already succeeded in >>>> adding custom level names to the configuration and making them be valid. I >>>> am just trying to clean it up a bit based on what Nick is suggesting. >>>> >>>> Ralph >>>> >>>> On Jan 25, 2014, at 6:30 PM, Scott Deboy <[email protected]> wrote: >>>> >>>> There's no way to add support for users to define level entries (name >>>> and value pairs as a new element in the config) and have us do the work to >>>> make those valid? That would get get rid of my request for additional >>>> levels, right? >>>> On Jan 25, 2014 6:15 PM, "Ralph Goers" <[email protected]> >>>> wrote: >>>> >>>>> The class is needed because it is a name and a value (two items) that >>>>> has to be represented as a single parameter to Logger methods. Using raw >>>>> int or String is not a good alternative. >>>>> >>>>> Ralph >>>>> >>>>> On Jan 25, 2014, at 4:54 PM, Scott Deboy <[email protected]> >>>>> wrote: >>>>> >>>>> If levels are just a name and a value why require a class at all? What >>>>> about just having it defined in the configuration. >>>>> On Jan 25, 2014 4:37 PM, "Ralph Goers" <[email protected]> >>>>> wrote: >>>>> >>>>>> Because we don’t know the class name that the Level belongs to. It >>>>>> is referenced in the configuration just as “DIAG”, not >>>>>> “org.apache.logging.test.ExtendedLevel.DIAG”. >>>>>> >>>>>> In any case I fixed it. I just annotated the new Level as a Plugin >>>>>> and then look up all the Level plugins in BaseConfiguration. Simply >>>>>> calling >>>>>> the getEnumConstants method on each of the classes does the trick. >>>>>> >>>>>> Ralph >>>>>> >>>>>> >>>>>> >>>>>> On Jan 25, 2014, at 4:26 PM, Paul Benedict <[email protected]> >>>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >
