[
http://issues.apache.org/jira/browse/LOG4NET-80?page=comments#action_12421084 ]
Nicko Cadell commented on LOG4NET-80:
-------------------------------------
If we are going to have to support both CallContext and HttpContext as storage
locations for the LogicalThreadContext, then we will need to support both
within the same app domain. Only certain threads processing ASP.NET requests
have access to the HttpContext, other threads should continue to use the
CallContext. (i.e. custom threads or thread pool work items).
This test could be done just by using:
if(HttpContext.Current!=null)
{
// store in HttpContext
}
else
{
// store in CallContext
}
I think that we need to do this test each time the property is looked up as the
calling thread may be part of an ASP.NET request, or it may not have anything
to do with the ASP.NET requests.
A good analysis of the situation is:
http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html
> Allow LogitcalThreadContextProperties to be stored in HttpContext.Items
> instead of CallContext
> ----------------------------------------------------------------------------------------------
>
> Key: LOG4NET-80
> URL: http://issues.apache.org/jira/browse/LOG4NET-80
> Project: Log4net
> Issue Type: Improvement
> Components: Other
> Affects Versions: 1.2.10
> Reporter: Ron Grabowski
> Priority: Minor
>
> According to these posts:
> http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html
> http://forum.springframework.net/showthread.php?t=572
> and this thread on the mailing list:
> http://www.mail-archive.com/log4net-dev@logging.apache.org/msg01236.html
> it might be a good idea to investigate storing LogicalThreadContext values
> inside the HttpContext.Items if log4net is being used within an ASP.Net
> application. Other projects such as IBatisNet, Spring.Net, Castle Project's
> Active Record, etc. do this. In a nutshell, IIS may change the thread on
> which a request is processed on durings the request's lifetime. Accoring to
> the post on springframework.net, a worse case scenerio is for each ASP.Net
> page lifecycle event to be switched to a different thread. Even though
> HttpContext uses CallContext internally its supposedly does other things to
> make it a safer place for storing per-request values.
> I haven't studied the other projects implementations in depth but the basic
> idea is to replace this code in LogicalThreadContextProperties:
> PropertiesDictionary properties =
> (PropertiesDictionary)CallContext.GetData(SLOT_NAME);
> with this:
> PropertiesDictionary properties =
> (PropertiesDictionary)contextAccessor.GetData();
> where contextAccessor is CallContextAccessor:IContextAccess,
> HttpContextAccessor:IContextAccessor, etc.:
> internal LogicalThreadContextProperties(IContextAccessor contextAccessor)
> {
> this.contextAccessor = contextAccessor;
> }
> The decision on which IContextAccessor to use could come from a factory:
> public class DefaultContextAccessorFactory : IContextAccessorFactory
> {
> private const string SLOT_NAME =
> "log4net.Util.LogicalThreadContextProperties";
>
> public IContextAccessor CreateContextAccessor()
> {
> // another implementation might _always_ use CallContext instead
> // of first testing for HttpContext
> if (HttpContext.Current != null)
> {
> return new HttpContextAccessor(SLOT_NAME);
> }
> else
> {
> return new CallContextAccessor(SLOT_NAME);
> }
> }
> }
> I haven't figured out a good way for LogicalThreadContext to know which
> factory to be initialized with. This was my first attempt:
> static LogicalThreadContext()
> {
> // we should retrieve the IContextAccessorFactory from the configuration
> system...
> IContextAccessorFactory contextFactory = new
> DefaultContextAccessorFactory();
>
> s_properties = new
> LogicalThreadContextProperties(contextFactory.CreateContextAccessor());
> s_stacks = new ThreadContextStacks(s_properties);
> }
> The problem is that IContextAccessorFactory should be coming from the
> configuration system some how. Contexts don't know about ILoggerRepository
> and vice versa. Maybe its acceptable for LogicalThreadContext's static
> constructor to always use the DefaultContextAccessorFactory when its
> initialized and the user can specify another factory via a setter.
> Has anyone actually run into a problem with requests being switched to
> different threads? I mostly understand the reasoning for it but I can't
> imagine it being a regular occurance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
