Hi Craig, Although Costin defended all the reasons to add a bit of configuration much better than I would be able to do, there are a couple of options to consider.
The rest goes inline: > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 06, 2002 5:16 PM > > On Wed, 6 Feb 2002, Paulo Gaspar wrote: > > > > > Hey, I am talking about the really minimal "log to a file" > > configuration that any logger supports and drawing the line > > after that. > > > > The "any logger supports" statement is why this proposal is on the > slippery slope. IMHO, the commons-logging API itself should not touch > configuration at all. > > Configuration is a feature of a particular *implementation* of logging. > The implementations we wrap all have their own configuration mechanism. > So does the simple logger implementation that writes to System.out (which > uses system properties). Using Velocity is made much easier for the beginner because there is a default logger configuration quite similar to what I am defending. It is the practical case. > If that's not enough for you, the appropriate step is to write a slightly > more sophisticated implementation of the simple logger that configures > itself through whatever mechanism it wants to use. Yes, it should always be easy to separate the configuration bit but: - I think its usefulness is big enough that it deserves to be a commons thing instead of just my thing; - It looks silly to have another project for that. > (Paulo, your argument on this philosophical issue made it clear that data > conversion, for example, is a feature of a DynaBean implementation, not > the DynaBean interface itself :-). Yeah, I like to: - keep thinks (especially interfaces) minimal; - separate features and concerns... because that opens the way to multiple options (and multiple combinations of options) while allowing that those not using a feature do not have to "pay" for it. And I stick to those principles on this issue too. There must be separation enough (on packages for sure and maybe even on jars) that the configuration stuff does not have to be there for those that do not use it. I just think that it is overkill to make another project for this. BTW... DynaBeans... they are still not minimal enough for much of the stuff I am doing. I have been thinking if I could use them instead of my "Records" but the extra bean (indexed properties and so) stuff really gets on the way for many things (e.g.: "moving data with names") because its interface promises too much. Me thinks there could be DynaBeans on top of Records. I will try to build a sandbox project around my Records and (the load of) related stuff and we probably can find synergies later. Well, even Records are not my basic layer. My basic layer is a set of interfaces and wrapper and utility classes that are letting me operate on "named values" in many ways I was not foreseeing a couple of months ago. I will get back on this later. > Craig Have fun, Paulo Gaspar -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
