Comments below...
robert burrell donkin wrote:
On 21 Dec 2004, at 14:04, Matt Sgarlata wrote:
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.
It's not obvious to me though... what implementations would JCL need to provide? Even if we introduce our own MessageSource interface similar to Spring's (which I've seen some other people in recent posts seem to be in favor of), that is only defining an interface, not an implementation. If we choose to fall back to java.util.ResourceBundle functionality when there is no MessageSource implementation to be found, we are once again simply bridging functionality that is already written. That is, the default MessageSource is implemented by java.util.ResourceBundle and we've kept JCL free of implementations.
If you're talking about the discovery stuff, well, that's over my head. But assuming for a moment that this did require JCL to do some "implementation"-type things for discovery, that doesn't mean that JCL should be given a free ticket to move away from being a bridge for all of the JCL, including functionality like enter/exit methods that are completely orthogonal to the discovery process!
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]
