I created https://issues.apache.org/jira/browse/LOG4J2-519 for this.
Feedback welcome.
On Tuesday, January 28, 2014, Remko Popma <remko.po...@gmail.com> wrote:
> 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<javascript:_e({}, 'cvml', '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>
>> 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
>>>
>>
