巧用CurrentThread.Name来统一标识日志记录(完结篇)

上一篇文章《巧用CurrentThread.Name来统一标识日志记录(续)》所述就是《巧用CurrentThread.Name来统一标识日志记录》里改用当前线程名统一记日志后的问题。 我在csdn里也提问了(here and here),很遗憾最终没有查到原因。不过,很欣赏@sp1234大哥中肯的意见:

设计软件,面向业务来设计,例如用一个自定义的变量来保存参数。这样不管这问题中不同的过程被调用时在同一个线程还是不同线程,变量的值都是一致的。

如果“高大上”到过分技术层面,由于我们不了解技术底层和问题,所以反而弄巧成拙。

当然,我倒不是刻意在tmp1构造器里去给当前线程的Name赋值。只能说,代码改动前就是在这个构造器里声明的logflag,所以,改动时自然就在这个构造器里给当前线程赋值。 没想到,就遇到了这个问题。

至于有同学发问说,ProcessRequest里获取不到当前线程Name,是不是因为不是同一个线程了,   我倒是测试了一下, 在tmp1.ashx.cs类里声明一个私有对象,在构造器里初始化, 然后在ProcessRequest里是可以取到的。   按这个应该可以推断出是同一个线程。   所以,为什么会出现帖子里的问题,的确不好分析。

姑且留作一个思考题吧。

最终的解决方案就是,取代构造方法而在ProcessRequest方法里给当前线程赋值。

public abstract class HandlerBase : IHttpHandler
{
    protected readonly LogHelperUtil _LogHelperUtil;

    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "application/json"; 

        Thread.CurrentThread.Name = string.Format("[{0}_{1:HHmmssfff}_{2}]", this.GetType().Name, DateTime.Now, Guid.NewGuid().ToString().Replace("-", "").Substring(0, 5).ToUpper());
        _LogHelperUtil = new LogHelperUtil();

        ... ...

    }
}
时间: 2024-10-11 20:40:50

巧用CurrentThread.Name来统一标识日志记录(完结篇)的相关文章

巧用CurrentThread.Name来统一标识日志记录(java-logback篇)

java版本支付中心,日志组件使用的是logback.logback.xml里日志pattern配置如下: <!--本地日志目录--> <property name="USER_HOME" value="${catalina.base}/logs/logback-srv" /> <property name="LOG_MSG" value="%X{sid}%d{yyyy-MM-dd HH:mm:ss.SSS

巧用CurrentThread.Name来统一标识日志记录

先看下面的日志: 2017/5/21 18:00:01 [OrderQuery_180001914_C72FF]请求支付中心参数:{"order_no":"KB201705210000165","sign":"e6c3559cd4b36458b180f15bfcd9b5a5"} 2017/5/21 18:00:01 [OrderQuery_180001914_C72FF]支付中心验签通过. 2017/5/21 18:00:01

巧用CurrentThread.Name来统一标识日志记录(续)

开篇不提前文.本文通过模拟场景来抛出问题. 我在web站点程序里新建一个tmp1.ashx文件.其类代码如下: using System; using System.IO; using System.Threading; using System.Web; namespace PaymentPlatform.Test { /// <summary> /// tmp1 的摘要说明 /// </summary> public class tmp1 : IHttpHandler { pu

用slf4j统一管理日志总结

参考网页:http://www.slf4j.org/ 一.使用slf4j统一管理并配置统一使用log4j日志 使用的jar:(slf4j-api-1.7.5.jar,jcl-over-slf4j-1.7.5.jar,jul-to-slf4j-1.7.5.jar,slf4j-log4j12-1.7.5.jar,log4j-1.2.12.jar) 因为项目中多个框架使用不同的日志或者现在修改以前项目中的日志框架改用另一种日志,所以使用slf4j统一管理日志会比较方便. 1.slf4j是一个接口标准.

Spring MVC异常统一处理(异常信息的国际化,日志记录)

JAVA EE项目中,不管是对底层的数据操作,还是业务层的处理过程,还是控制层的处理,都不可避免的会遇到各种可预知的(业务异常主动抛出).不可预知的异常需要处理.一般dao层.service层的异常都会直接抛出,最后由controller统一进行处理,每个过程都单独处理异常,且要考虑到异常信息和前端的反馈,代码的耦合度高,不统一,后期维护的工作也多. 同时还必须考虑异常模块和日志模块.国际化的支持. 因此需要一种异常处理机制将异常处理解耦出来,这样保证相关处理过程的功能单一,和系统其它模块解耦,

巧用Logcat把日志记录到文件

在一些开发阶段,产品已经小部分分发出去,在出现问题的时候,我们希望用户能把当时的Logcat日志也发过来提供给程序员进行分析,这里介绍一个巧妙利用logcat命令行进行日志记录的方法,不用自己写日志记录的代码. Android的shell里面提供个logcat的命令,是用来查看系统日志的,这个命令同时支持日志过滤.日志记录到文件,并支持自动日志文件滚动.控制日志文件大小.因此,我们在系统启动的时候,用Runtime调用一下logcat命令,启动一个进程,就可以把我们通过Logcat发的日志记录到

SLF4J - 一个允许你统一日志记录API的抽象层

一.什么是SLF4J 我们在做Java开发时,如果需要记录日志,有很多日志API可供选择,如: java.util.logging Apache log4j logback SLF4J又是个什么东东呢?为什么使用SLF4J比使用log4j或者java.util.logging更好呢?这是因为与所有提到的这些日志记录库相比,SLF4J没有真正地实现日志记录,相反它只是一个允许你使用任何处于后端的日志记录库的 抽象层 . 如果你正在编写内部或者外部使用的API或者应用库的话,那么你真的不需要让使用你

关于日志记录的总结

前段时间,公司的一个项目,需要做很多的数据接口和同步程序,于是就遇到了日志记录的问题,何时记录,如何记录,哪些要记哪些不用记等问题.针对日志记录的问题,经过一系列讨论,终于达成了统一的处理办法.解决了各个模块系统,不同的开发人员,日志记录不统一,随意的问题.今天终于抽出时间把这个问题总结并结合网络上的资料,进行整理. 为什么要记录日志 记录日志是调试程序,监视程序运行的一种重要的方式,主要有两个目的:bug的及时发现和定位,显示程序运行状态.正确详细的日志记录能够快速的定位问题.同样,通过查看日

Java日志记录的事儿

一.java日志组件 1.common-logging common-logging是apache提供的一个通用的日志接口.用户可以自由选择第三方的日志组件作为具体实现,像log4j,或者jdk自带的logging, common-logging会通过动态查找的机制,在程序运行时自动找出真正使用的日志库.但由于它使用了ClassLoader寻找和载入底层的日 志库, 导致了象OSGI这样的框架无法正常工作,由于其不同的插件使用自己的ClassLoader. OSGI的这种机制保证了插件互相独立,