news <[EMAIL PROTECTED]> wrote on 12/21/2004 02:01:07 PM: <snip/>
> > And yes, I'm leaning towards EXPLICITLY naming methods to encourage best > > practices. To use the distinction made by Curt, I'm pushing the trace > > level methods towards diagnostic logger function, and stepping away from > > other uses entirely. I'm going to refrain from doing a full brain dump on > > all the fun thoughts now running through my head... [separating trace > > level methods and messaging/admin level methods into seperate interfaces.. > > ok I lied]. > > OK, I'm being serious again. I think there are two problems with "best > practices": (1) they change and (2) they are in the eye of the beholder. > Nothing can be deemed "best" without making a value judgement, which > means that reasonable people can disagreee as to what is the "best" > practice. Agreed. Looking for balance, there are some things that are more clear than others. > Bringing this back to the situation at hand, you think enter/exit are > best practices, I think they're as useful as the SUPERTINY log level. > But let's not take my word for it. Consider that Log4J doesn't include > enter/exit and it is the pioneer logging framework that's still going > strong despite an attempt to hijack its charter by including logging in > the Java language itself. This leads me to believe your argument that > enter/exit is a best practice is debatable at best :) > > > 3 levels stand out clearly to me: > > > > component level tracing [flow] - particularly useful in a larger system I want to turn on logging that tracks component boundries. When I enter my component [or robert's brick], and when I leave it. Perhaps log data exchanged across the boundry. > > class level tracing [flow] Ok, now that I'm IN my component, I want to track the flow between objects / methods. Again, data exchanged on method invocation / return. This corresponds to the proposed enter/exit. I'm agreeing with comments by others, in that [generally] I don't want to log just any old thing here, but I for loggers that do support multiple log levels, would be useful to have this without the next level down.. > > additional detail Capture details on internal data, track low level flow if desired... everything else. > I still don't understand this distinction, but I am comfortable taking > your word for it that this is very important. It would probably be a > great feature for Log4J instead of JCL :) > > >>>richard's proposal to add symantic methods (rather than severities) is > > > > > >>>therefore interesting. exit and entry tracing is common. at the > > > > moment, > > > >>>this works rather poorly when JCP is used with log4j: most people log > >>>these at trace which is mapped to debug by the bridge. unfortunately, > >>>this has the effect of making debug level almost unusable. separate, > >>>symantically meaningful methods would have the advantage that the > > > > bridge > > > >>>will know enough to make better choices. > >> > >>-0. This is moving JCL out of the realm of bridging logging APIs and > >>into the realm of providing logging implementations. For Log4J, > >>enter/exit methods will end up being mapped to Log4J's DEBUG level. > >>This means that JCL will have to provide the implementation that > >>converts the enter/exit calls into DEBUG calls with a specific format. > > > > > > This is what the thin wrapper DOES. Not sure I understand your issue. > > > > > >>What format should be used? Are we going to force one on users of Log4J > > > > > > We should adopt a helper method to do such formatting, and use it [common] > > across all components to standardize this as much as possible. Where > > logger impls support such, we pass as much as makes sense straight > > through. > > > > Let's not get hung up on formatting issues, the POINT is to capture > > information, enable the developers, etc. > > > > > >>or make it configurable? And if it's configurable, that stinks of JCL > >>becoming a logging *implementation* rather than *bridge*. Yuck! If I > >>was a committer (you're probably glad I'm not!) I would probably -1 the > >>enter/exit methods. > > > > > > No problem, I'd just keep beating at your arguments until my last dying > > breath. ;-) > > Hehe that worked on me last time :) I think it won't this time though! I'm not done yet :) ******************************************* Richard A. Sitze IBM WebSphere WebServices Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
