In addition to the above, we could provide a tool to generate a MyLogger
interface with 14 method signatures for each custom Level name. This would
be an offline tool that users would use only once.
But this tool is optional...
On Monday, January 27, 2014, Remko Popma <remko.po...@gmail.com> wrote:
> Sure, but what's wrong with the idea?
> The user provide their own interface, so that interface exists at compile
> time.
> The interface uses annotations, so it does not need to explicitly refer to
> a custom Level instance. Only the /implementation/ needs to know about the
> custom Level instances, and the implementation could be generated at
> runtime (I hope :-) ).
>
> On Monday, January 27, 2014, Ralph Goers <ralph.go...@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.po...@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.go...@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 <nicho...@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" <nicho...@nicholaswilliams.net>
> wrote:
>
> Here's a split-off thread for discussing how we can make using custom
> levels easier. Some on the team have expressed a desire to make it even
> easier. Given hypoth
>
>
