avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [logkit] ContextMap
Date Wed, 25 Jul 2001 15:46:30 GMT


Peter Donald a écrit :
> 
> 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.

Is it safe to put security information in the ContextStack ? Anyone can
reset and change its content anywhere in the code.

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

That's exactly how I used it for the Cocoon extension : clear the
context, and add data in a known order and rely on that order in the
formatter. I've found this a little bit hacky ;)
> 
> 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.

And we could have the ContextMap entries formatted with
"%{context:user}", "%{context:hostname}", etc.
> 
> 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?
> 

DecoratorTarget is fine, but IMO its usefulness is limited :

- most of the application-level information will not be known by the
LogTarget, and will still require the application to feed the
ContextMap,

- it can know about "environmental" info (e.g. class name), but will
have to add in the ContextMap *all* the information that can potentially
be output by the associated formatter, which in some cases can be
overkill, especially if the format pattern is user-configurable. IMO,
the formatter should do as much of the job as possible.

> 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               |
> *-----------------------------------------------------*
> 

Sylvain
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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