Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions

[Ceki Gülcü <ce...@qos.ch>]

The strategy we adopted when renaming Category as Logger and Priority
as Level at the time log4j 1.2 was released, consisted of having Logger
extending Category, and Level extending Priority. This is quite a
non-intuitive approach but with solid technical reasons behind it.

[1] http://www.geocrawler.com/mail/msg.php3?msg_id=6535547&list=8711
[2] http://www.geocrawler.com/mail/msg.php3?msg_id=6542095&list=8711

[1] explains the nature of the problem. In particular why Category
extending Logger was not an option.

[2] Detials of N. Wollf's brilliant strategy which was quickly adopted
by log4j in 1.2 for renaming Category as Logger and Priority as Level.

There are two inconveniences with Nichola's method. First, since
Logger extends Category, Category could not be marked as @deprecated
because that would cause all dependent code to show deprecation
warnings ad nauseum. Second and more importantly, although Nichola's
strategy solves compile time issues, it still leaves room for binary
(or runtime) compatibility problems. These problems are fortunately rare
and are being addressed on a case by case basis..

With log4 1.2 we are allowing people to migrate to Logger and Level
classes. In log4j 1.3, we will swap Catgory and Logger, that is
Category will inherit from Logger and not vice versa. Category will be
marked as @deprecated in addition to the existing bold and red warning
telling people to move to Logger. Similarly, in 1.3, we will swap
Level and Priority, that is Priority will inherit from Level and will
be marked as @deprecated.

Thus, our migration strategy has been:

in log4j 1.2) Tell users to migrate to Logger and Level,
in 1.3) to formally deprecate Category and Priority,
in 1.4) to remove Category and Priority.

It's quite a complicated, far from self-evident process.

At 08:22 PM 5/19/2004, Adam R. B. Jack wrote:
> > >BTW: I also wish folks had updated long ago, we'd have had a much smaller
> > >transition, be having discovered this sooner.
>
>I worded this poorly, and failed to get my point across. I meant ... I wish
>projects had stopped using deprecated stuff a year ago, heck ... or two.
>Progress has to be allowed to happens, so API change will happen ... and I
>agree it is a long time to carry around deprecate baggage.

[snip]

>Adam

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



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