[
https://issues.apache.org/jira/browse/LOG4NET-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055946#comment-16055946
]
Lehel Bara commented on LOG4NET-568:
------------------------------------
When you explicitly call the SetThreadPrincipal second time, it will throw an
exception. It doesn't throw though if a generic principal was created before
due to a Thread.CurrentPrincipal call... I know, it is pretty shitty
functionality in the core library. And I would never figure it out if I don't
stumble on that ancient post and answer...
> 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)
