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 >>> >> > > >
