I would really like everyone's feedback on this. I have two questions: 1. Does this fulfill everyone's requirements? Another way of asking this is: would you use this in your own projects? (If not, why not?)
2. What do you think of this approach? Obviously code generation has drawbacks. For one thing, IDE refactoring tools don't work and API changes don't cause compile errors in the generator itself, only in the generated code. (I plan to add a JUnit test that generates a custom logger, compiles it and executes the custom logging methods so we can at least catch issues during the build.) The advantage is that it is open-ended and can deal with any custom level users can dream up. Is this trade-off acceptable? Are there other ways to solve this? Remko On Tuesday, January 28, 2014, Remko Popma <remko.po...@gmail.com> wrote: > 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> 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); > > >
