On Jan 28, 2014, at 5:43 PM, Remko Popma wrote: > 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?)
Personally, no. I don't like the code generation for IDE integration issues. I'd prefer an interface I wrote. > 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? Also IMO, I would tend to steer away from only generating a concrete class. The interface and implementation should be separate. Imagine a Log4j fixing a bug in the generation code and releasing 2.0.1 or whatever. Now the user has a generated implementation, so they can't /just/ upgrade their Maven dependency. They /also/ have to re-generate their code. That's a pain. However, with the interface and implementation separate, the interface probably doesn't have to change, and the implementation will change as soon as they fire up their app with the latest Log4j. Also, if you separate the interface and implementation, you can make the generation of the interface optional. The user can /choose/ whether to generate the interface or create the interface themselves. Then the implementation generates at runtime. Nick > > 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); >
