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:
http://marc.theaimsgroup.com/?l=log4j-dev&m=99952347000483&w=2
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
