While acknowledging that while we all orbit the same sun, we also stand in different time zones and see it differently... :-)
news <[EMAIL PROTECTED]> wrote on 12/18/2004 10:44:11 AM: > Noel J. Bergman wrote: > > Simon Kitching wrote: > >>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 > > > > > > Actually, I agree. I'd prefer to see that semantic state encoded in the log > > message, which I feel is much cleaner. > > > > --- Noel > > +1. Just because the JDK 1.4 log does this, doesn't mean that we have > to enforce this behavior on all logging implementations. Why not just > leave it generic? If someone wants enter/exit methods, they can define > their own: > > public static void enter(Log log, Class clazz, String method); > public static void exit(Log log, Class clazz, String method); The proposal is for more than a the simple helper methods, it is for the [potential] underlying implementation below. Where possible, these SHOULD be mapped to a finer level than 'debug', but not as fine as 'trace'. By naming them 'enter/exit' instead of 'finer', we encourage their use in a particular fashion... if you feel that such strong "best-practice" enforcement is inappropriate, then let's not throw the dog [and I know it's a dog ;)] out with the bath water. We'd like at least one more trace level, see below. > Personally, I am against introducing logging that is more specific than > TRACE. In practice, I think it's hard to explain even the distinction > between TRACE and DEBUG (i.e. - the projects I've seen tend to use one > or the other almost exclusively if they're not using INFO or higher for > the message). Again, just because JDK 1.4 offers FINEST, FINER doesn't > mean JCL has to. What happens when the next implementation comes along > that offers 42 different logging levels, including TINY, VERYTINY, > EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels? There are many uses for different levels of trace logging [general term, not JCL trace]. One such for which I advocate better support is: 1. Tracing as we cross component boundries [currently this would be JCL debug on classes representing component API's]. I want to log information that helps me understand what's coming in, and what's going out, at a COMPONENT level [component TBD as you like]. 2. Tracing as we cross class/method boundries [currently we propose this with enter/exit]. 3. Tracing of additional low level information [currently this would be JCL trace]. Two trace levels is simply not enough. Granted we can play games with loggerNames, but feel this unnecessarily imposes multiple "logger name" schemes where the "class name" is more than sufficient for most uses. IN PARTICULAR, if we want to document this as a "best-practice" in the users guide, then we need also to ensure that there is a consistent "logger name" scheme being used across components, that there are no [or minimal] collisions... class name really simplifies this. ******************************************* Richard A. Sitze IBM WebSphere WebServices Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
