Logger is the main interface for logging. I am not sure why we would want to refactor it. It is also part of the public API so any changes must be backward compatible. The LogEvent is the class that captures the logging data. It has several variations as you can see. Although it is not part of the API, it is used by lots of things so any changes have to be done carefully. Finally, the configuration classes are how the user tells Log4J what to do. All the various configurations use AbstractConfiguration.
All this is to say that the classes you named are at the heart of Log4J. That doesn't mean they can't be improved, but whatever is done must be done very carefully. Ralph > On Jul 19, 2017, at 5:00 AM, Dominik Psenner <[email protected]> wrote: > > Hi, > > You should do atomar modifications in single commits and file one pull > request for a sensible set of patches. Remember to also write sensible > commit messages that explain what is done and why it is done. This allows > easy and fast code reviews. Github is great for doing all but the actual > coding. > > Cheers > > On 19 Jul 2017 1:47 p.m., "João Paulo Lemes Machado" <[email protected]> > wrote: > >> Hello everyone. >> >> My name is João Paulo, I am a graduate student the Federal University of >> Uberlandia, Brazil. >> >> I was analyzing the modularization of some classes of log4j, and I >> identified some opportunities for cohesion improvement in the following >> classes: >> >> Logger >> DefaultConfigurationBuilder >> ConfigurationBuilder >> MutableLogEvent >> AbstractConfiguration >> Log4jLogEvent >> RingBufferLogEven >> >> Could you please take a look and tell me if it's viable? >> >> Maybe some of these classes could benefit from some kind of refactoring >> that we can discuss. >>
