Yes, I was saying that. But, unless I'm misunderstanding, Scott doesn't want the user to even have to write the interface. He wants them to just configure it and the interface become available "magically." I was pointing out that there's a disconnect between when the configuration is used (runtime) and when the user needs the interface (compile time).
Unless we provide a code-generation tool for the user to run from the command line or from Ant/Maven/Gradle, they're going to have to write the interface themselves. Nick Sent from my iPhone, so please forgive brief replies and frequent typos > On Jan 26, 2014, at 22:49, Remko Popma <[email protected]> wrote: > > 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 >> <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >>> 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 >> >>> <[email protected]> >> >>> 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" <
