Sorry if I misread. Any mechanism that supports custom levels and gets as close as possible to the ease of use of the built-in logger interface is fine with me.
On Monday, January 27, 2014, Gary Gregory <[email protected]> wrote: > Please read my message again. I talk about wrapping not extending. > > Gary > > > -------- Original message -------- > From: Remko Popma > Date:01/26/2014 18:17 (GMT-05:00) > To: Log4J Developers List > Subject: Re: Enums and Custom Levels - completed. > > Scott, > The way I interpreted Gary's idea was that based on user-specified custom > levels, we would generate an extension of the Logger interface that has a > method for each of the custom levels (well, actually 14 methods for each > level :-) ). > I haven't really thought about how users would specify their custom > levels, as long as the tool can know what methods to generate. > > We could go one step further and generate the Level subclass from > configuration as well. I suppose that would entail adding a new <Levels> > element, with sub-elements like <Level name="DETAIL" intLevel="450" />... > Is that what you are thinking of? > > I would be fine with that too, but would like to first focus on generating > the extended Logger interface. > > > > On Mon, Jan 27, 2014 at 5:29 AM, Scott Deboy <[email protected]>wrote: > > Is there a way to generate code/update the Levels enumeration so a new > Level class isn't required? > > Would be great to be able to use logger.detail("Detail message"); > > Is that what you're thinking of, Remko? > > On 1/26/14, Ralph Goers <[email protected]> wrote: > > I haven’t done anything to directly do that. However, custom levels need > to > > be mapped to the standard levels in several places. It would be simple to > > add support for that wherever you want it. Level.StdLevel.getStdLevel() > is > > the method used to do that. > > > > Ralph > > > > On Jan 26, 2014, at 7:45 AM, Scott Deboy <[email protected]> wrote: > > > >> Are these serialization-wise going to be the same as standard levels? > >> > >> Receivers and apps like Chainsaw would benefit from not requiring the > >> originating level class be included in the classpath. > >> > >> I'm thinking about socketreceiver and to a lesser extent > >> logfilepatternreceiver. > >> > >> Scott > >> On Jan 26, 2014 7:28 AM, "Scott Deboy" <[email protected]> wrote: > >> So I assume we could build on this by adding the ability to generate > these > >> custom levels from the config, with no user provided class required? > >> > >> > >> > >> On Jan 26, 2014 12:58 AM, "Ralph Goers" <[email protected]> > >> 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 <[email protected]> > >> > 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 crea > >
