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]
