If there's a global "isWeb" setting, you wouldn't be able to easily
tell certain loggers (i.e. a certain namespaces) to use CallContext.
What about setting the LogicalThreadContext's storage at the logger
level?
<root>
<level value="ALL" />
<appender-ref ref="FileAppender" />
<logicalThreadContextProperties
type="log4net.Util.LogicalThreadContextProperties" />
</root>
<logger name="Company.Website">
<level value="ALL" />
<logicalThreadContextProperties
type="log4net.Util.HttpContextLogicalThreadContextProperties" />
<appender-ref ref="WebsiteFileAppender" />
</logger>
<logger name="Company.Website.BackgroundThreads">
<level value="ALL" />
<logicalThreadContextProperties
type="log4net.Util.LogicalThreadContextProperties" />
<appender-ref ref="BackgroundThreadsFileAppender" />
</logger>
In the example above, the Company.Website.BackgroundThreads namespace
contains loggers who don't have access to HttpContext.
Appenders already do something similiar with their SecurityContext
property. Its possible for every appender to have a unique
SecurityContext implementation. We could make a
LogicalThreadContextPropertiesProvider class that mimics
SecurityContextProvider in that the DefaultProvider property returns
either a normal CallContext storage provider or a HttpContext storage
provider. Would there also need to be specialized property patterns
that know where to look? My idea sounds overly complex :-/
--- josh robb <[EMAIL PROTECTED]> wrote:
> On 2/16/06, GlennDoten <[EMAIL PROTECTED]> wrote:
> > Josh, why bother with a flag called isWeb? If HttpContext.Current
> is not
> > null then you know you are in the context of a web app; otherwise
> you
> > aren't. It works great just checking the HTTP context because then
> the same
> > code can execute in a web app or a non-web app.
>
> Thanks for the feedback - I initially thought of this - but I thought
> it made sense to keep the new behaviour optional. (It's possible to
> imagine circumstances where you'd rather use the CallContext even if
> you're in the middle of a web request).
>
> Are we getting close to agreement about what the patch should look
> like? If so I can knock something together - to hopefully generate
> some more discussion.
>
> j.
>
