logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: [logging] Log4J forward compatibility with version 1.3
Date Sat, 18 Jun 2005 06:33:02 GMT

On Jun 18, 2005, at 12:02 AM, Simon Kitching wrote:

> The current migration strategy actually is:
> in 1.3)
>  * formally deprecate Category and Priority
>  * change Priority/Level class hierarchies so that all existing code
>    compiled against log4j1.2 which uses method
>       Logger.log(String, Level, String, Throwable)
>    breaks (throws an exception when used with log4j 1.3)
> The changes currently in 1.3 *won't* break code that just uses the
> logger.debug(...), logger.warn(...) etc. methods. But any code that
> explicitly passes a Logger object will break - and that includes just
> about every log4j wrapper library out there, including JCL.
> Every application out there in the wild which uses JCL will stop  
> working
> when log4j 1.3 is installed, unless they also upgrade their JCL  
> library
> to some version compatible with log4j 1.3.
> I understand the need to phase out Category and Priority. But I'm
> surprised there isn't a more elegant way to do this phaseover. As the
> plan currently stands, code that uses the new Logger/Level classes  
> (and
> avoids all use of the deprecated classes) classes will still break
> against release 1.3.
> It would appear that significant thought went into this when Logger  
> and
> Level were first introduced - but unfortunately the links to the  
> actual
> technical discussion are broken so I can't see why a better choice
> wasn't possible.

I think this is one of the missing messages (the Nicholas Wollf (sic,  
actually Wolff) strategy) way back in September 2001:


This message was part of a larger thread which occurred prior to the  
release of log4j 1.2 and discussed the introduction of Level and  
Logger.  I assume the other link (description of problem) is to an  
earlier message in the same thread or at least of the same  
approximate time.  Neither really addresses the end of life of the  
Priority and Category class.

The inversion of the relationship was to allow Priority and Category  
to be deprecated without also tagging Level and Logger as  
depreciated.  However, there may be alternatives where sufficient  
constructors et al are deprecated that would it impossible to use the  
classes without triggering a deprecation warning without actually  
deprecating the classes.  If there is a decent proposal, I could  
support it and may take a shot at it unless somebody beats me to it.

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

View raw message