avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject [logkit] ContextMap
Date Wed, 25 Jul 2001 06:01:57 GMT
Hi,

For a while now I have mentioned that ContextStack was a bad design choice. 

I originally added it in so you could determine what important "state" was in 
process when a log event was issued. For instance you could use context to 
record the current security group under which you are performing or the 
transaction participating in etc. 

So the context "a.b.c" could mean you are running this in security permission 
set "c", nested in "b" which is nested in "a". Or it could be that you are in 
transaction "c" nested in transaction "b" (which is nested in "a"). etc

The problem is that this feature is rarely needed. In fact most times I used 
it I stored a other information in there (ie "<hostname>.<user>.<action>")

and relied on the order placed in stack to interpret meaning of each element. 
This is of course an error prone activity and a considerable abuse of the 
mechanism.

So what I am proposing is that associated with each LogEvent we can 
optionally have an extra ContextMap. This object would contain a map between 
string keys and objects. Some example entries

"user"      ->"fred"
"hostname"  ->"helm.realityforge.org"
"ipaddress" ->"1.2.3.4"
"interface" ->"127.0.0.1"

"caller"    ->"com.biz.MyCaller.method(MyCaller.java:18)"
"source"    ->"1.6.3.2:33"
etc

So it would contain all the possible variables that you could need.  Most of 
these variables are bound to a particular thread and relatively "static". The 
others "caller" and "source" are per-log event.

So what I propose is that associated with each thread is a ContextMap that 
you can add *stuff* to. In cases you need to add extra per-call information 
(say the caller variable) you can add a "Decorator" LogTarget (ie 
CallerDecoratorTarget) that adds to LogEvents ContextMap. This would have the 
advantage that getting caller id would still work across when you hand them 
off to AsyncLogTarget.

Thoughts?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

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


Mime
View raw message