On Thu, 26 Jul 2001 01:46, Sylvain Wallez wrote:
> 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 ?
Nope - not at all ;) I had complete control over classloader though so it
wasn't as bad ;)
> > 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 ;)
yup - me too ;)
> > 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,
yep.
> - 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.
good point. I guess formatter is the right place for detecting stack in that
case then.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
