logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Using Custom Levels with a Custom/Wrapper Interface
Date Mon, 27 Jan 2014 04:49:35 GMT
Nick, I thought that you meant that users would provide their own
interface, like this:
public interface MyLogger extends Logger {
    @LoggingLevel(name="DIAG")
    void diag(String message);
    // optional other methods
}

That way, this interface exists at compile time.

On Monday, January 27, 2014, Nicholas Williams <
nicholas@nicholaswilliams.net> wrote:

> Scott, invokedynamic and javassist...those are all /runtime/ things. The
> user needs Logger#notice to be available at compile time. Those are not
> compatible.
>
> Nick
>
> Sent from my iPhone, so please forgive brief replies and frequent typos
>
> > On Jan 26, 2014, at 22:37, Scott Deboy <scott.deboy@gmail.com> wrote:
> >
> > Yes, I would like to declare in the config:
> >
> > Level: NOTICE, value: 232
> >
> > And in Java code be able to use logger.notice("some message").
> >
> > But I think that'd require invokedynamic..which would probably
> > require..javassist/ASM?
> >
> > I'd be ok with anything that's really close to that :)
> >
> > Scott
> >
> >
> >> On 1/26/14, Ralph Goers <ralph.goers@dslextreme.com> wrote:
> >> Scott would like users to add a level definition to the logging
> >> configuration and have everything else happen auto-magically.  That
> would
> >> happen at run-time which is a bit late since the methods need to be
> >> available at compile time.
> >>
> >> I believe Scott said he would be fine if users had to do
> >>
> >> logger.log(SomeClass.SomeLevel, "message);
> >>
> >> but even that requires "SomeClass" to be available at compile time.
> >>
> >> So what Scott says he would like and what Nick is proposing are two
> >> different things.
> >>
> >> Ralph
> >>
> >>
> >>
> >>> On Jan 26, 2014, at 8:09 PM, Remko Popma <remko.popma@gmail.com>
> wrote:
> >>>
> >>> I actually thought that Nick's idea was the answer to that: users
> create a
> >>> custom interface, something like this:
> >>>
> >>> public interface MyLogger extends Logger {
> >>>    @LoggingLevel(name="DIAG")
> >>>    void diag(String message);
> >>>    // optional other methods
> >>> }
> >>>
> >>> They get an instance of this interface by calling:
> >>> LogManager.getCustomLogger(MyLogger.class);
> >>>
> >>> LogManager has access to the processed configuration. The config has
> >>> <Levels><Level name="DIAG" intValue="450"> elements. During
> configuration
> >>> processing, the custom Level instances are created and registered, so
> on
> >>> the first call to LogManager.getCustomLogger(MyLogger.class), the
> MyLogger
> >>> instance is created and cached. Also, at this point the annotations are
> >>> parsed to see what Level instance the MyLogger implementation will
> pass to
> >>> the Logger.log(Level, String) method when the "diag" method is called.
> >>>
> >>> What is still open in this scenario is how the instance is created.
> Proxy?
> >>> Or generate source & compile? Or use a byte code library?
> >>>
> >>> On Monday, January 27, 2014, Ralph Goers <ralph.goers@dslextreme.com>
> >>> wrote:
> >>> I am going to have to echo what Nick said.  If you can think of a way
> to
> >>> make
> >>>
> >>> logger.log(SomeClass.SomeLevel, "hello world");
> >>>
> >>> work without actually creating SomeClass then please share!
> >>>
> >>> Ralph
> >>>
> >>> On Jan 26, 2014, at 7:45 PM, Nick Williams <
> nicholas@nicholaswilliams.net>
> >>> wrote:
> >>>
> >>>> It would not be possible to do this strictly through configuration
> >>>> because the user needs a compiled interface to code against. Where is
> >>>> that compiled interface to come from?
> >>>>
> >>>> Nick
> >>>>
> >>>>> On Jan 26, 2014, at 9:40 PM, Scott Deboy wrote:
> >>>>>
> >>>>> If there is a way to support this strictly through configuration
that
> >>>>> would be ideal.
> >>>>>
> >>>>> I'm trying to find a way to remove my request for additional built
in
> >>>>> levels but through configuration instead of adding them ourselves.
> >>>>>
> >>>>> Scott
> >>>>> Scott
> >>>>>
> >>>>> On Jan 26, 2014 7:38 PM, "Nick Williams" <

Mime
View raw message