logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject RE: [logging] Log4J forward compatibility with version 1.3
Date Sat, 18 Jun 2005 05:02:06 GMT
On Fri, 2005-06-17 at 21:08 -0700, Scott Deboy wrote:
> We are shooting ourselves in the foot if we don't support binary compatibility, considering
how many folks are using commons-logging.  
> The adoption rate of log4j 1.3 will be dramatically slower than if we supported binary
> (from the link):
> ----------
> 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.
> ----------
> This seems fine for me.  Does it address the problem?

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.



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

View raw message