Semantic methods (other than severity) belong somewhere other than Log. Entry and exit (and other to-be-determined semantic methods) can be supported right now without changing commons-logging at all, by passing in a POJO or Map in as the event's message and relying on the enterprise logging framework to provide extension points in the event processing and mechanism for adding user-defined attributes to the logging event.
Log4j can provide this support now. See MapFilter and ReflectionFilter: http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/varia/ I'm sure this is the exact opposite of what others had in mind - they'd like a stronger contract - but at least this gives folks something to look at and think about. Scott -----Original Message----- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tue 12/21/2004 5:39 AM To: Jakarta Commons Developers List Cc: Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0? On 18 Dec 2004, at 23:07, Scott Deboy wrote: > Enter and exit should not be defined as severities. This is useful > information, but orthogonal to a logging event's severity attribute. > > One way to provide entry/exit information is to overload the logger > methods to take a map, and require the user to adhere to use-case > specific conventions for keys and values. > > For example, to track entry and exit as we cross component boundaries, > these entries might be sufficient to identify an event: > > Key Name Value > ------------------------- > boundary.type component > boundary.state entry > > Similarly, to track entry and exit as we cross class boundaries: > > Key Name Value > ------------------------- > boundary.type class > boundary.state exit > > This provides a general mechanism for extending what information an > event provides - without codifying use-case specific attributes as > methods in commons-logging. > > Again, the user would be responsible for conforming to naming > conventions for the map entries (possibly with the aid of helper > methods to build the map) in order to discover these use-case specific > events. interesting :) this is a classic component design dilemma: more specific, strongly contracted methods or fewer, more generic ones. i'm not really convinced either way as yet. JCL has benefitted from a compact, strongly contracted API and it would be good to keep it that way. IIRC ceki (in the past) convinced me (and probably a lot of others too) that there really isn't very much use in a plethura of logging levels. applications shouldn't really need anything much lower than debug. even for components, trace is more than a little debatable (though we went for it). a load of severities may look good in a policy document but are much less useful in practice and their usage patterns do not really generalize well. so, i don't really see the need for any more severities in 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. (so, i'm a little unsure about this issue at the moment.) - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
