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 <garydgreg...@gmail.com> 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 <scott.de...@gmail.com>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 <ralph.go...@dslextreme.com> 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 <scott.de...@gmail.com> 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" <scott.de...@gmail.com> 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" <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>
> >> > 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 crea
>
>
