If there's a global isWeb setting, you wouldn't be able to easily
tell certain loggers (i.e. a certain namespaces) to use CallContext.
What about setting the LogicalThreadContext's storage at the logger
level?
root
level value=ALL /
appender-ref ref=FileAppender /
Josh,
I've been doing something similar with remoting Contexts. I'm
putting some objects into a new Context, and using ContextProperties to
inject message sinks which intercept some calls and add information to
the Context Property. In this case i'm not using the
ThreadLogicalContext as i
Ron Grabowski [EMAIL PROTECTED] wrote:
I don't think HttpContext is always available...especially inside the
Global.asax.cs methods and/or inside CacheItemRemovedCallback methods.
HttpContext is available during the life cycle of a Http request. This
includes any event handler in Global.asax
On 2/16/06, josh robb [EMAIL PROTECTED] wrote:
Conceptually - this is what I'm proposing:if(isWeb and HttpContent.Current != null){ // store context in HttpContext.Current.Items} else { // sore it in CallContext.}
Josh, why bother with a flag called isWeb? If HttpContext.Current is
not null then
I've seen an email from Piers Williams in december asking about this.
Basically - in an ASP.NET application - none of the existing contexts
are safe to use.
I'd like to remedy this. There are two ways forward that I can see.
1. Add a new WebContext class.
2. Change the ThreadLogicalContext
Yep - Thats the email I was talking about.
Thanks for the reply.
j.
Sorry, I blanked and completely glazed over the first line of your email. :)
-Chad
On 2/15/06, josh robb [EMAIL PROTECTED] wrote:
Yep - Thats the email I was talking about.
Thanks for the reply.
j.
I don't think HttpContext is always available...especially inside the
Global.asax.cs methods and/or inside CacheItemRemovedCallback methods.
According to this article:
http://www.odetocode.com/Articles/112.aspx
HttpContext is just a wrapper around
System.Runtime.Remoting.Messaging.CallContext.
