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.
kewl!
---------- Forwarded Message ----------
Subject: [logkit] ContextMap
Date: Wed, 25 Jul 2001 16:01:57 +1000
From: Peter Donald <[EMAIL PROTECTED]>
To: "Avalon Development" <[EMAIL PROTECTED]>
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
