> What about the option of having commons-logging 1.0.3 and earlier work > with log4j 1.2.8 and earlier, and commons-logging 1.0.4 and later do > whatever it feels like (since that's now possible with Ceki's recent > changes)?
> I'm not gung ho about bending over backwards in order to not > remove an API that's been deprecated for two years: that's the purpose > of deprecation, to give people a warning that the deprecated item will > be gone.
Sure, but the opportunity of a smooth transition has been lost. Deprecation w/ an overlapping strategy (allowing both to operate) so folks can make the transition semi-transparently & not impose Jar-Hell on users/users environments, now that is a beautiful thing.
BTW: This isn't just C-L. BTW: I also wish folks had updated long ago, we'd have had a much smaller transition, be having discovered this sooner.
Keep in mind that
1) log4j 1.3 is nowhere near an official release date
2) As of May 19th, approx. 12:00 GMT, the 3 projects directly suffering from the log4j changes, namely C-L, Excalibur, Velocity (**), have been provided with solutions ensuring smooth transition from 1.2.x to future 1.3.
3) Did I mention that 1.3 is nowhere near official release?
** Velocity: to be verified.
ps: All hail gump.
regards
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
