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.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 hypothetical custom levels DIAG and NOTE, the following
>>>> would be nice to have:
>>>>
>>>> logger.note("message");
>>>> logger.diag("message");
>>>> etc.
>>>>
>>>> We're to discuss how best to approach this. My proposal (from previous
>>>> email):
>>>>
>>>> > Allow the user to define an interface that /must/ extend Logger. That
>>>> > interface may contain any methods that match the following signatures
>>>> > (the interface must have at least one method and there is no limit to
>>>> > the number of methods it may have):
>>>> >
>>>> > void [methodName](Marker, Message)
>>>> > void [methodName](Marker, Message, Throwable t)
>>>> > void [methodName](Marker, Object)
>>>> > void [methodName](Marker, Object, Throwable t)
>>>> > void [methodName](Marker, String)
>>>> > void [methodName](Marker, String, Object...)
>>>> > void [methodName](Marker, String throwable)
>>>> > void [methodName](Message)
>>>> > void [methodName](Message, Throwable t)
>>>> > void [methodName](Object)
>>>> > void [methodName](Object, Throwable t)
>>>> > void [methodName](String)
>>>> > void [methodName](String, Object...)
>>>> > void [methodName](String throwable)
>>>> >
>>>> > Each method /must/ be annotated with @LoggingLevel(name =
>>>> > "levelName"). Now LogManager has a few new methods:
>>>> >
>>>> > <T extends Logger> T getCustomLogger(Class<T> loggerClass)
>>>> > <T extends Logger> T getCustomLogger(Class<T> loggerClass, Class<?>)
>>>> > <T extends Logger> T getCustomLogger(Class<T> loggerClass, Class<?>,
>>>> > MessageFactory)
>>>> > <T extends Logger> T getCustomLogger(Class<T> loggerClass,
>>>> > MessageFactory)
>>>> > <T extends Logger> T getCustomLogger(Class<T> loggerClass, Object)
>>>> > <T extends Logger> T getCustomLogger(Class<T> loggerClass, Object,
>>>> > MessageFactory)
>>>> > <T extends Logger> T getCustomLogger(Class<T> loggerClass, String)
>>>> > <T extends Logger> T getCustomLogger(Class<T> loggerClass, String,
>>>> > MessageFactory)
>>>> >
>>>> > The user can then obtain such a logger like so, etc.:
>>>> >
>>>> > MyLogger logger = LogManager.getCustomLogger(MyLogger.class);
>>>> >
>>>> > Log4j will generate an implementation of MyLogger that extends the
>>>> > default implementation, cache that implementation so that it doesn't
>>>> > have to be implemented again, and then instantiate/cache the logger
>>>> > instance like normal.
>>>>
>>>> Others have suggested deriving the level name from the method name
>>>> instead of using an annotation. That's a viable alternative.
>>>>
>>>> Matt Sicker asked:
>>>>
>>>> > And can't getCustomLogger also provide a default method that uses the
>>>> > getClassName method?
>>>>
>>>> I think you misunderstand the purpose of the Class<T> argument. It has
>>>> nothing to do with the logger name--it's the class of the Logger
>>>> interface to automatically implement.
>>>>
>>>> Nick
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>>
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
