avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [LogKit][PATCH] 'method' field for PatternFormatter
Date Wed, 25 Jul 2001 15:04:41 GMT
On Thu, 26 Jul 2001 00:43, Sylvain Wallez wrote:
> Then comes the CocoonLogFormatter which introduces 3 new patterns :
> - "uri" : the servlet request URI, which is totally cocoon-specific
> - "thread" : prints the thread name. This is also cocoon specific since
> it relies on the ContextStack set by the Cocoon servlet.
> - "class" : prints the name of the class that called Logger.
> This last pattern isn't Cocoon-specific and was designed to be as
> CPU-cost-aware as possible : the caller class is computed only if
> "%{class}" is present in the pattern. I explained the inner details to
> Stuart which was asking about performance :
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=99597653529789&w=2

sounds good.

> The only drawback (see javadoc) is that it doesn't work with
> AsyncLogTarget. Computing the caller class in LogEvent as proposed by
> Stuart would circumvent this limitation, but require computation for
> each event logged, even if not used later, which IMO is too costly.

It's something I have been considering a bit lately and actually today I sent 
a proposal how to deal with this. I have attached it below. Basically it 
comes down to attaching a map to each logger. Then any arbitrary application 
specific information could be stored in that map. 

Some of that information is static (thread name in this case) and some is per 
log event (ie class and uri in this case). To add in this per request 
information you add in a DecoratorTarget (basically just a link in chain of 
log targets). That gets resources and populates ContextMap. To extract it you 
would use something like "%{map:class} %{map:uri}" etc.

I would be interested in what you think of the idea.

> Since there seems to be interest for it, the files are attached and I'd
> be happy to see the non-Cocoon specific part of them included in a
> future LogKit release.


----------  Forwarded Message  ----------
Subject: [logkit] ContextMap
Date: Wed, 25 Jul 2001 16:01:57 +1000
From: Peter Donald <donaldp@apache.org>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>


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

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

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

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.


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

View raw message