On Fri, 23 Dec 2005, Jacob Kjome wrote: | | A bit of a sidetrack from the current discussion, but just how big is | log4j-1.3 going to be and just how polluted with 1.2.xx stuff are we going to | make it? Originally, a lot of stuff was refactored and/or removed and | replaced by, arguably, better implementations. Last changes I made, I had | Log4j-1.3 and Log4j-1.2.xx working with LogWeb. I figured that if something | that uses Log4j internals like LogWeb works with both, then 1.3 was good to | go. | | Now we've got everything from Log4j-1.2.xx coming back into Log4j-1.3, plus | all the changes and additions made for 1.3 in there as well. From my | perspective, maybe the current 1.3 should have just moved to 2.0 and 1.3 | should have been developed off the 1.2 branch. 1.3 seems to be turning into a | monster with everything 1.2.xx being added back in to make it binary | compatible. Log4j is already somewhat bloated as it is. Any larger and its | going to burst. | | thoughts?
That you should have had the TRACE extension and these smaller things be 1.3, and then have the current 1.3 be 2.0. The "keep binary compatibility" camp is most definately right when it comes to the 1.x set of releases, but a 2.0 would, at least to me personally, clearly point out that "here (might) be (largish) differences". Specfically, all the deprecated stuff, like Category, is obviously _gone_. Given that one also would have a different package (log4j2), this would work out nicely. The shim-idea for the _application side_ where a binary compatible log4j "1" wrapper logs til log4j2 Loggers also sounds like a very interesting and nice idea. PS: Maybe one could have the 1.x and 2.0 read the same config file(s), so that the migration would be _very_ smooth, given the shim and also possible loading of two different systems? Regards, Endre. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
