You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by João Paulo Lemes Machado <le...@gmail.com> on 2017/07/19 11:47:04 UTC
Opportunities for cohesion improvement and refatoring.
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.
Re: Opportunities for cohesion improvement and refatoring.
Posted by Matt Sicker <bo...@gmail.com>.
I think AbstractConfiguration (along with XmlConfiguration and
JsonConfiguration) seems like a good candidate. I've had it on a list of
mine to try to refactor one day. As Ralph said, Logger is pretty off limits
being a public API (the duplication is somewhat intentional for user
convenience and optimizations), and LogEvent would be somewhat difficult.
I'd add that LogEvent has a serialization format to worry about, but we've
also been discouraging the use of serialization, so that may not be as big
a deal.
On 19 July 2017 at 07:39, Apache <ra...@dslextreme.com> wrote:
> 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 <dp...@gmail.com> 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" <
> lemesmachado@gmail.com>
> > 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.
> >>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Opportunities for cohesion improvement and refatoring.
Posted by Apache <ra...@dslextreme.com>.
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 <dp...@gmail.com> 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" <le...@gmail.com>
> 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.
>>
Re: Opportunities for cohesion improvement and refatoring.
Posted by Dominik Psenner <dp...@gmail.com>.
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" <le...@gmail.com>
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.
>