-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 robert burrell donkin wrote: > 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. When we have cleared how to proceed at all, I will help out - not saying that I will do the hole thing :) > > >>>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. Actually, as I told before, for maven we would need to create a subproject for each bridge implementation to have it right. Then we could also do the tests properly with maven. BUT this would be ugly for maintainence and by default would create a jar for each bridge (commons-logging-log4j12.jar, ...). I will raise this issue on maven-dev for m2, because it is even not targeted with m2. > > >>>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. Okay. I will update this in my local code. Anyways I have to supply a new patch sooner or later. > > >>>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. You are right with what you are saying. To make it clear what I meant. If someone is directly implementing the Logger interface and not extending AbstractLogger even though suggested, he will have no guarantee for compatibility. I do not know if this is acceptable. As I pointed out, the big issue for me is, if one day guys from log4j or whatever decide to directly implement the JCL API. But the suggestion in javadoc is at least reducing the harm about compatibility while not giving up the flexibility of an interface.
Maybe we can prevent all this if we look for the issues on the list and in bugzilla before we release this Logger thingy. I have found the indirect proposal for generic access to "log" and "is*Enabled" methods via a typesafe enum (NOT a JDK 5.0 enum to make this clear). Actually I like this idea. But while for the "is*Enabled" method this is peanuts, for a generic "log" method implemented in the AbstractLogger (or vice versa: implementing all methods "trace", "debug", ...) this will increase the level of indirection. I am not worrying too much about performance, more about the way the logger gets the actual caller-method from the stack-trace (you now these output "[MyClass.myMethod][DEBUG]Hello World"). BTW: the "vice versa" could at least make it be on a constant level - just one level higher than now. Anyways I am sure there are also guyz on this list who bleed for performance and would not like that to happen. Please confirm this for me guyz. So in this case we could only live with a "log" method that directs to the existing logging methods causing the trouble of different stracktrace levels. Can someone give me a hint if this would be hard to solve. Or is everybody saying "this proposal should go to hell right away" :) > > - robert Take care Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTCu7mPuec2Dcv/8RAmcZAJ9cBRg/c41zb2yem5RGNUMpdlrTfwCfbcmO sRcGjdY1z700tV4jMjnpXWw= =uiH0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
