robert burrell donkin wrote:
<snip>
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. What format should be used? Are we going to force one on users of Log4J 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.
this one is an interesting dilemma.
it's pretty obvious to me that some standard implementations beyond a simple bridge are going to be required for the proposal.
for the moment, i'm more interested in the technical issues rather than the issue of scope. many (most?) of the extensions to commons logging under consideration extend the scope of JCL. where this (hypothetical) code ends up packaged is another matter: if JCL becomes a compact API plus extensions (some optional, some standard; some libraries, some byte-code manipulators) then that's the stage when the commons (probably collectively) will need to think about organization and scope.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
