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
>
>
