On 11/18/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I don't like this approach.
most people don't like this approach the first time they see it: it feels wrong but give it time and think about it carefully before rushing to judgement
I think we should wait to refactor this component until we'll switch to java 5 as the required jvm so we can introduce a Logger interface with the mixin's methods we need.
the james class hierarchy already has superclasses that provide logging. (the new approaches to logging being discussed are all 1.2 IoC without bytecode enhancement so james is pretty much stuck with this approach.) so, nothing new is being introduced architecturally by this innovation. the tactical advantage is that it leads to more readable code with less effort from the developer. the strategic advantage is that it factors out and consolidates the code that performs the logging. the architectural disadvantage is that you introduce an artificial element into the class hierarchy but in the case of james, this is already present. the performance cost is an additional call to a final method.
If you want to avoid complex evaluation for debugging you will have to use the isXXXXEnabled anyway, so I don't see so much advantages is this approach. You only optimize the concatenation and not the other calls that could be needed by the log statements.
as is typical, the vast majority of logging statements i've seen in the james codebase are just basically string concatinations. the few cases where additional calls are required would need guard calls. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
