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 w
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, Aaron Morton <[EMAIL PROTECTED]> wrote:
> Perhaps you could create something similar (add objects to the
> GlobalContext) to read values from the HTTPContext as a work around.
Nice - Ok - for the two things I've mentioned so far (User Identity
and Requested Url) this would be a fine s
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
On 2/16/06, GlennDoten <[EMAIL PROTECTED]> wrote:
> Josh, why bother with a flag called isWeb? If HttpContext.Current is not
> null then you know you are in the context of a web app; otherwise you
> aren't. It works great just checking the HTTP context because then the same
> code can execute in a
