I've started to work on implementing a source code generator along the
lines described below.
Does anyone disagree with this approach?
I was thinking to name the tools Generate$ExtendedLogger and
Generate$CustomLogger and put the Generate class in the log4j-api project
under org.apache.logging.log4j.util or create a new package called
org.apache.logging.log4j.experimental.
Thoughts?
On Tuesday, January 28, 2014, Remko Popma <remko.po...@gmail.com> wrote:
> 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<javascript:_e({}, 'cvml', 'garydgreg...@gmail.com');>>
> wrote:
>
>> On Mon, Jan 27, 2014 at 2:15 PM, Nick Williams <
>> 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 lev
>>
>> --
>> E-Mail: garydgreg...@gmail.com | 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
>>
>
