On Sun, 2005-10-09 at 21:20 +0200, Joerg Hohwiller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > robert burrell donkin wrote:
<snip> > > 2 for me, the documentation for this would be critical. i'd like to have > > a firm commitment for good documentation to be produce to go with this > > patch. > I am very willing to produce documentation for this issue. But this proposal > was > asked at least 2 times before on this list and then died. If I get the feeling > that my issue will not be dropped later, I will "invest" more time. But still > I do not have a clue if my patch is acceptable. good enough for me :) > > 3 should probably go through the old bugzilla reports and see whether > > there are any other bits and pieces which are missing from Log and > > should be added to log2. > My intention always was to focus on the "getChildLogger" method and not to > overload the issue. In the end the hole thing might be dropped because another > feature was added but caused a controverse discussion. > But I agree that this would be a good idea. Maybe we could vote for each > different issues that will arise. that'd be the way to proceed > But anyways someone has to do the list-crawling. to ship another release someone's going to have to go through the bugzilla's in any case. > > 4 not happy about upgrading the log4j dependency at the same time. > The current code in SVN does not compile with an older log4j. so i see :) > So I just added some sort of "bugfix" to my patch. releases need to be compiled against 1.2.6 but the maven build will need to run against 1.2.12 for now. i'll fix this sometime soon and add some notes into the comments section for that dependency. > > 5 should use a string buffer in getChildLoggerName. > Okay, I was thinking about this... but since only one string construction > takes > place, this is happening anyways: the compiler will do this for you. i agree in general terms but JCL is used in a wide variety of JVMs so it's best to code these things in. not a big issue, though. > > 6 bit unsure about fitting a superclass (AbstractLogger) just to provide > > a utility method. sometimes this can prove harmful in the long run since > > it may limit inheritance options for the future. can't think of any > > reason why this would apply in this case right now, though. > The reason is NOT just to provide a utility method. It is to have the ability > to > add a method to the "Logger" interface later without breaking compatibility. not sure i understand this correctly. so long as Logger is an interface, methods cannot be added without breaking compatibility. in order to be able to add new methods, the Logger logical interface would need to be implementated as an abstract class. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
