On Sat, 2004-12-11 at 15:24, Noel J. Bergman wrote: > It disturbs me that what seems to me to be a reasonable and small set of > requirements --- along with what appears to have been considerable > forethought based upon real world issues, and experiences supporting many > developers --- appears to be discounted a bit too out of hand. I hope my > perception is wrong. > > Does anyone really dispute the requirement to support localization for log > messages or the additional JSR-mandated logging requirements? If not, then > let's work constructively towards satisfying the requirements. And not by > relying upon some IDE's tooling.
I am quite sure the IBM Websphere team have a good idea of what J2EE environments need in terms of logging. And I believe their proposal should be given serious consideration. The question is whether the implementation of those requirements is a good fit for commons-logging or not. Commons-logging is used in many environments that the Websphere team may *not* be interested in. I will dispute localisation of log messages if this: (a) forces commons-logging to terminate support for underlying logging implementations that don't provide this feature, or (b) forces commons-logging to include a "configuration layer" that it didn't previously need so that it can implement i18n within commons-logging. In neither case would this mean the requirements are wrong; it just means (IMHO) that the implementation shouldn't be in commons-logging. (Note: it's not clear to me whether IBM's proposal has problems (a) or (b) or not). My initial thoughts were that i18n support was a good idea. But the more I think about it, the more concerns I have about whether these can be included in commons-logging without making it unfit for purposes it is currently used for. I also dispute adding APIs to commons-logging if they encourage poor software design, just because JSR-47 has that API. I've been convinced by the arguments put forward in this thread that explicit enter/exit methods taking class+method strings should not be encouraged because of that (in addition to the practical issue of what to do with logging implementations that don't have methods taking class/method names). I look forward to seeing further discussion on i18n support + logging config, and would be very happy to see improvements made to JCL - as long as they fit. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
