You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Ralph Goers (Jira)" <ji...@apache.org> on 2020/04/04 22:29:03 UTC

[jira] [Updated] (LOG4NET-568) Would be nice to avoid accessing the Thread.CurrentPrincipal

     [ https://issues.apache.org/jira/browse/LOG4NET-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralph Goers updated LOG4NET-568:
--------------------------------

LOG4NET is now dormant.  

> Would be nice to avoid accessing the Thread.CurrentPrincipal
> ------------------------------------------------------------
>
>                 Key: LOG4NET-568
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-568
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Builds
>    Affects Versions: 2.0.8
>         Environment: win 10 x64, otherwise it seems to be not an environmental issue
>            Reporter: Lehel Bara
>            Priority: Minor
>         Attachments: stacktrace.jpg
>
>
> Hello,
> We had a weird issue in our product: at one point we set the default principal for newly created threads using AppDomain.CurrentDomain.SetThreadPrincipal(some_own_principal), however, the new threads were using the generic principal. After a fair amount of internet digging it turned out that IF the Thread.CurrentPrincipal is accessed, the SetThreadPrincipal won't set anything, it will just silently fail. You can read more about this issue here: https://social.msdn.microsoft.com/Forums/vstudio/en-US/f9a67b32-7c9b-4893-bf08-5a02203318d5/weird-threadcurrentprincipal-behavior?forum=netfxbcl
> As it turned out the only place where the Thread.CurrentPrincipal is used, is where we initlialize Log4Net.
> Even though this is rather an issue on the .net library, IF there is away, it would be nice to avoid accessing the thread.currentprincipal
> cheers,
> Lehel



--
This message was sent by Atlassian Jira
(v8.3.4#803005)