The JPA criteria API manages to generate a Foo_ class for the entity class
Foo, and that seems to work out fine.
On 26 January 2014 21:45, 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
>>
>>
>
--
Matt Sicker <boa...@gmail.com>
