这个项目解决的问题是？
thelight1 opened this issue · comments
不是很理解这个项目的作用，到底是为了解决了什么问题？
根据 sofa-common-tools 的规范对常用日志实现（Logback、Log4j2 和 Log4j）均进行配置（配置日志输出文件和格式），当应用引入二方包或者中间件时，根据应用中已有的日志实现并选择该日志实现能够正确解析的配置文件来初始化完成二方包或者中间件的日志配置来完成日志的输出，并同时不会和某一个具体日志实现绑定。从而完成在不用业务配置额外的 appender 和 logger 或者业务不用修改任何配置的情况下，完成日志空间打印的隔离能力。
疑问1：
中间件或二方包引入什么日志框架，并不会影响到应用的的日志打印呀。
应用引入中间件或二方包，并不一定需要进行appender和logger配置的修改。
这些都可以通过slf4j提供的桥接包，或者log4j2提供的桥接包(log4j->log4j2)解决。
既然不影响，为什么要用sofa-common-tools包，将简单的问题搞复杂了。
疑问2：
“完成日志空间打印的隔离能力“
这里的空间隔离是指？是指打印到不同的日志文件？
如果是的话，这个完全可以通过将logger配置成包名，再配置相应的appender的方法解决。
中间件或二方包引入什么日志框架，并不会影响到应用的的日志打印呀
这个其实并不是绝对的，比如中间件或者二方包引入的日志框架和应用本身期望的日志实现有冲突，那么就行您说的需要额外的桥接包去完成。而且，还要告诉用户，我们中间件的日志实现是 A（绑定 A 不能改变，那么业务就只能将就我们），而你的是 B ，造成冲突的话，你需要按照我们指定的方式去解决，并且由于业务的历史原因，业务可能会存在很多 new Appender() 深度依赖 B 的情况，按照社区的桥接包是没办法解决的（社区的桥接包都是从接口层面解决的，基本是相同的类全路径对应不同的实现完成桥接）。而且在升级引入的过程中，由于没有类隔离的机制，所有的依赖均在一个 ClassLoader 加载的范围内，这种冲突（也可能是不同版本造成）会更加明显，这样就给业务用户在使用我们的中间件造成很大的困扰。相反如果中间件不依赖任何的日志实现，业务期望用什么实现打印，中间件就自动使用其日志实现去打印，对业务而言，不会在日志使用上因为中间件的引入而带入任何困扰。
“完成日志空间打印的隔离能力“
每个中间件均是独立打印，并和业务的分开，中间件之间通过独立的“日志空间”隔离开，这样就删里面有相同的包名或者 Logger Name，通过空间 Namespace 的隔离，也不用中间件之前再去协商和修改。我们不期望给业务带来任何升级或者使用的困扰，期望业务在使用的时候，能够 丝般润滑，同样 N 个中间件同学在使用的时候，也期望大家丝般润滑，不用再去协商改包名或者其它。