[
https://issues.apache.org/jira/browse/LOG4NET-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055859#comment-16055859
]
Dominik Psenner commented on LOG4NET-568:
-----------------------------------------
If nobody should access Thread.CurrentPrincipal what should be the purpose of
setting it in the first place? According to
https://msdn.microsoft.com/en-us/library/system.appdomain.setthreadprincipal(v=vs.110).aspx
the method should throw a PolicyException if "The thread principal has already
been set.".
> 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
(v6.4.14#64029)
