I plan on catching up on all this tomorrow night. Gary
On Tue, Jan 28, 2014 at 6:43 PM, Remko Popma <remko.po...@gmail.com> 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?) > > 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); >> >> >> -- 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
