More thoughts on CustomLogger/ExtendedLogger source code generation:
Perhaps I was overcomplicating things...
Why don't we generate source for a concrete class instead of an
interface+implementation?
If users want to /extend/ Logger, this class would extend
AbstractLoggerWrapper (which has the standard debug(), info(), warn(), ...
methods).
If users want to hide the standard methods, the generated class would
simply not extend AbstractLoggerWrapper, so the only public methods would
be the generated methods for the custom log levels.
This allows users to generate both extended loggers (with extra methods)
and custom domain specific Loggers (like a logger that only has defcon1(),
defcon2(), defcon3() methods).
Note: this would also enable users to /take away/ existing log4j log levels.
Suppose you don't like the FATAL or TRACE log levels?
Simply generate a custom logger with levels ERROR=200 WARN=300 INFO=400
DEBUG=500.
Since this is a wrapper, there is no need for API changes or additional
methods on LogManager: the generated custom logger has factory methods that
internally call the existing LogManager.getLogger() methods and wrap the
resulting Logger.
So in client code, users would obtain a custom logger this way:
MyLogger logger = MyLogger.create(MyClass.class);
Thoughts?
On Tuesday, January 28, 2014, Gary Gregory <garydgreg...@gmail.com> wrote:
> On Mon, Jan 27, 2014 at 2:15 PM, Nick Williams <
> nicho...@nicholaswilliams.net <javascript:_e({}, 'cvml',
> 'nicho...@nicholaswilliams.net');>> wrote:
>
>> I would veto such a change, and here is my technical justification:
>>
>> You will break EVERYTHING currently using the Log4j 2 API.
>>
>> EVERYTHING that EVERY Log4j 2 user has currently written will have to be
>> changed to use StandardLogger instead of Logger. That's not even
>> considering the fact that Logger (or ILogger as the case may be) is *the*
>> industry standard for logger interface names that provide info(), warn(),
>> and other methods. I know that APIs can change when something's still beta,
>> but this is a HUGE CHANGE.
>>
>> However, what I WOULD be okay with is creating a SimpleLogger interface
>> for things like log(Level, ...), etc. and having Logger extend SimpleLogger
>> to provide info(), warn(), and so on. This would be backwards compatible
>> and abide by industry norms.
>>
>
> Of course, let's not get caught up in the names here and focus on the
> design first. What matters is that the current interface in split between a
> generic Level agnostic parent and a DSL sub-interface. I agree that 80/20
> says that "Logger" should be the name of the interface that has info(),
> warn() and so on. The parent can be called LevelLogger for example since it
> must be called with a Level. I do not like "SimpleLogger" because it does
> not describe anything and 'simple' feels like a judgment call.
>
> Gary
>
>
>
> Nick
>
> On Jan 27, 2014, at 12:46 PM, Gary Gregory wrote:
>
> On Mon, Jan 27, 2014 at 10:24 AM, Paul Benedict <pbened...@apache.org>wrote:
>
> I propose this:
>
> 1) If you are willing to view standard levels as a type of DSL, then you
> should refactor the Logger interface to separate those concerns. Create a
> new superinterface that contains everything else. This is what custom
> loggers will extend.
>
>
> That's brilliant! The Logger interface contains methods like log(Level,
> ...) and StandardLogger extends Logger to provide info(), warn() and so on.
>
> This let's me create a custom Logger (DEFCON example) AND an extension to
> StandardLogger with refined levels (NOTICE, DIAG, VERBOSE).
>
> This makes it clear that a Custom Logger is different than an Extensible
> Logger to StandardLogger.
>
> Gary
>
>
> 2) The customer loggers not only register an interface but also the
> implementation that goes with it.
>
> 3) Retrieve a custom logger as follows:
> <T extends LoggerSuperInterface> T Logger.getCustomLogger(T t);
>
> Paul
>
>
> On Mon, Jan 27, 2014 at 8:51 AM, Gary Gregory <garydgreg...@gmail.com>wrote:
>
> I also want to avoid extending Logger for domain specific applications.
> For medical devices for example I could only have critical, warning,
> advisory.
>
>
> -------- Original message --------
> From: Remko Popma
> Date:01/27/2014 09:15 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
>
> How about starting with something very simple at first?
>
> We provide a tool that generates the source code for a custom logger
> interface.
> To invoke the tool the user passes it the fully qualified name of the
> interface, and a list of NAME=INTLEVEL custom log levels.
> The generated source code contains both the interface and an
> implementation. The implementation is an inner class of the interface (so
> users only need to manage one single file).
> The generated interface is annotated with the class name of the
> implementation class.
>
> At runtime, users call LogManager.getCustomLogger(Class, String) to get a
> custom logger instance.
> The LogManager then uses the annotation on the interface class to
> instantiate objects of the implementation class.
>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com <javascript:_e({}, 'cvml',
> 'garydgreg...@gmail.com');> | ggreg...@apache.org <javascript:_e({},
> 'cvml', 'ggreg...@apache.org');>
> Java Persistence with Hibernate, Second
> Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
