[jira] [Commented] (LOG4NET-80) Allow LogitcalThreadContextProperties to be stored in HttpContext.Items instead of CallContext

["Dan Turner (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4NET-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015733#comment-13015733 ] 

Dan Turner commented on LOG4NET-80:
-----------------------------------

Are there any updates on this?  I am very interested in this feature.  As a mitigation strategy I am using a PatternLayoutConverter to spit out information from HttpContext.  This works but is clunky and I would greatly prefer a log4net vanilla solution.

> Allow LogitcalThreadContextProperties to be stored in HttpContext.Items instead of CallContext
> ----------------------------------------------------------------------------------------------
>
>                 Key: LOG4NET-80
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-80
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Other
>    Affects Versions: 1.2.10
>            Reporter: Ron Grabowski
>            Priority: Minor
>         Attachments: httpContextPatch.patch
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira