logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Duffin <pduf...@volantis.com>
Subject Re: Binary compatibility between versions of log4j
Date Tue, 11 Jun 2002 14:18:38 GMT
Ceki Gülcü wrote:
> Here is a slightly more complicated version of the same:
> Problem)
> My company is considering adopting log4j as its logging framework in a
> new project which depends on product X which also depends on log4j
> version 1.1.  However, we are worried about the removal of the
> Category and Priority classes in future log4j releases. (The javadocs
> suggest that these classes may be removed in 2H2003.) How can we be
> sure that the removal of the Category and Priority classes will not
> break our application once it is released to our customers.
> Solution)
> In your new project make sure that you only use the Logger and Level
> classes, never referring directly to Category and Priority classes or
> instances. As for product X, since it is based on log4j 1.1, unless
> product X uses a subclass of Category, it will also run with log4j
> version 1.2. Assuming product X is actively maintained, it is likely
> that product X will gradually replace references to Category class
> with references to Logger. Developers have ample time to perform the
> change. Assuming product X is updated to only use the Logger class,
> when and if the Category and Priority classes are removed in a future
> version of log4j, you will not be affected.

This is not really a solution for a couple of reasons.
1) You say that product X will run with log4j 1.2
   "UNLESS it uses a subclass of Category". I have to care about those
   ones which do use a subclass of Category.

2) Even if product X is actively maintained it does not mean that the
   logging mechanism can or will be changed.

   Product X may not be able to change to use 1.2 for exactly the same
   reasons that I cannot, as there may be a hundred other products out
   there which all rely on product X using 1.1.

   Product X may be able to change but there just may not be enough
   time for the developers to do it as managers would much rather see
   that couple of days which was spent changing the 3000+ files used to
   add some new piece of functionality.

> The key factor here is time.  Eventually, the vast majority of
> applications will be based on log4j 1.2 and later versions. In say
> 2004, very few people will be using older log4j versions, especially
> in light of strong deprecation warnings.

The phrases "eventually", "the vast majority", "very few" are not part
of the solution, they *are* the problem. Either log4j will maintain
binary compatability for some of its APIs or it will not there is no
middle ground.

As has been illustrated in other posts log4j does not have a very
good history when it comes to binary compatability.

This message may contain confidential information and will be protected
by copyright. If this email isn't for you then we'd be grateful if you
could notify Volantis by return and delete it. You should not copy,
disclose or distribute any of its contents.

Any reply may be read by the recipient to whom you send it and others
within Volantis Systems Ltd.

Although we aim to use efficient virus checking procedures we accept no
liability for viruses and recipients should use their own virus checking

To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

View raw message