I'm very curious! Can't wait to see it. Go for it! On Sunday, January 26, 2014, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> I have completed the work on custom levels. It uses a variation of Nick’s > “extensible enum” class. The major difference with what he proposed is > that the custom enums must be declared in a class annotated with > @Plugin(name=“xxxx” category=“Level”) for them to be usable during > configuration. > > Are their any objections to me checking this in? I’ll be doing the commit > at around noon Pacific Daylight Time if I don’t hear any. > > Ralph > > > > On Jan 25, 2014, at 7:08 AM, Ralph Goers > <ralph.go...@dslextreme.com<javascript:_e({}, 'cvml', > 'ralph.go...@dslextreme.com');>> > 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<javascript:_e({}, 'cvml', '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<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > >