[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    Re: AppenderSkeleton.isActive, etc
From:       Curt Arnold <carnold () apache ! org>
Date:       2005-02-28 17:25:22
Message-ID: a98ba559ad5d99191c5719ef903385bd () apache ! org
[Download RAW message or body]


On Feb 28, 2005, at 10:00 AM, Ceki Gülcü wrote:
> Curt's changes preserve absolute backward compatibility. Although
> quite reasonable, they add an additional layer of
> complexity. Preserving backward compatibility is a very important
> goal. At the same time, it can eventually lead to over-convoluted and
> unmaintainable code. In my opinion, it is more economical to ask
> authors of appenders to make small updates to their code in order to
> adapt to changes in log4j 1.3. Note that we are talking about small,
> easily performed adaptations. I believe that trying to preserve
> *perfect* backward compatibility is beyond our resources.
>
> To summarize, I think that log4j committers have to choose between:
>
> 1) For the sake of improvement, we allow for small changes, even in
>    core interfaces, at the cost of perfect backward compatibility.
>
> 2) No, perfect backward compatibility is an overriding principle, more
>    important than other considerations.
>
> Comments?
>

It shouldn't be a decision between an absolute fanatical perfect 
backwards compatibility and total chaos.  However if I had to choose 
one at this time I would choose fanatical backwards compatibility.  
What I have been suggesting is that our general policy is to preserve 
backwards compatibility and that we discuss any exceptions either on 
discovery or prior to committing and require a vote when we knowingly 
break backwards compatibility.

A substantial proportion of code that uses log4j has to run in the 
context of another application or server and has no control over the 
version of log4j that is in use.  I think it highly desirable that code 
that worked properly with 1.2 would continue to work properly.  If 
there are compelling reasons and no reasonable alternative, we could 
consider adding additional requirements (like adding the detach method 
RepositorySelector) that can work under both 1.2 and 1.3.  Only under 
the most extraordinary conditions, should we be forcing applications to 
choose between 1.2 and 1.3 or to add substantial complexity to be able 
to operate in both environments.

As I mentioned in a previous email, it appears that several significant 
projects have found themselves having to choose between 1.2 and 1.3.  
We should review the problems that they encountered and attempt to 
resolve them.  They are serving as advance warning of the problems that 
will be encountered in much greater number as log4j 1.3 is evaluated by 
the wider body of log4j users.  Breaking Hivemind may not be a big 
deal, but it may be a warning that we are breaking 10 or 100 times the 
number of non-ASF applications.

At this point I would consider the "core" interfaces like Appender and 
Layout nearly untouchable.  The have proven that they are sufficient to 
represent the essential characteristics of their abstraction.  Any 
additional enhancement or optimization could be exposed using 
additional interfaces or hidden within implementations.

In this particular instance, I would -1 both the additions to the 
Appender interface and the renaming of the activateOptions virtual 
method.  The objectives of both (as have been revealed so far) could be 
accomplished without breaking backwards compatibility with very minimal 
additional complexity.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]