commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Tue, 21 Dec 2004 18:08:15 GMT
news <news@sea.gmane.org> wrote on 12/21/2004 08:04:09 AM:

> robert burrell donkin wrote:
> > 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.
> 
> Good point.  I think this would be an excellent distinction for a 
> logging implementation (e.g. Log4J to make).  Until such a distinction 
> is already implemented in an existing logging framework, I don't think 
> JCL has any business doing work (i.e. - implementations! bad!) in this 
area.

This distinction IS made in some frameworks.  It's made in the JSR-47 f/w 
implicitly by it's description of the "finer" level.  There are others I'm 
familiar with that support these types of methods explicitly, though in 
different forms that what the proposal contains.

> >> 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.
> 
> Again, something a logging implementation may decide is appropriate, but 

> something I don't think sould be in JCL.

Absolutely agree.  It is interesting, but WAY to fat.

> > 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.
> 
> +1, I agree with you and Ceki.  TRACE is debatable (I personally like 
> it), more than TRACE is silly.

Well... call them what you will, I want em'!! lol

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].

3 levels stand out clearly to me:

component level tracing [flow] - particularly useful in a larger system

class level tracing [flow]

additional detail


> > 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. ;-)

> > (so, i'm a little unsure about this issue at the moment.)
> > 
> > - robert
> 
> Matt
> 

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message