lingxiao.wu

这个任务给我试试

「weopen star」这个任务交给我试试

> @lingxiao-wu 方便也提交到2020和2021分支吗？ 最近在酒店隔离没带电脑，你先合并一下吧嘿嘿🤤🤤🤤

> `appender` 启停功能，可以考虑引入 `logback` 的 `` 标签的扩展依赖： > > ``` > > org.codehaus.janino > janino > ${janino.version} > > ``` > > 将 `enabled` 配置映射到 `springboot` 中。 > `appender` 启停功能，可以考虑引入...

> 我还是更倾向于直接使用listener方式来处理,因为这样用户需要关心的不再是yml+xml的方式,而是关注在yml中即可,而且对seata的维护者来说,使用listener方式对日志是拥有更高的掌控权,logback的配置掌控权在用户侧,我们只能通过文档等方式去帮助用户配置,如果使用listener方式的话,假设用户的日志输出是个"123",然后我们发送到kafka中的msg是{"msg":""123""} 这时就会出现json解析问题,如果我们用listener方式,我们可以不用用户去配置appender是哪个,我们可以直接集成kafkalogappender去对相关日志进行转义之类的 > 目前引入logback ``标签支持后，可以配合``标签动态的加载logback配置，seata维护者可以在xml中借助logback的``和``根据用户在yml中指定的配置来动态加载标签。用户只需要按照文档指导修改相关的logging.extend配置来管理logback日志收集appender的配置。如果后续appender的提供者有新特性，使用xml+``标签支持也很方便，而listener方式的话需要直接操作API的方式来支持新特性，感觉不太灵活。 > 但是从对日志掌控权的方面考虑，listener的配置方式可能更好，虽然他不灵活，但是可以稳定的提供服务，appender的一些关键配置信息也会被更规范的管理，同时xml+``配置方式使配置文件的修改成本增加，可能出现用户随意修改导致配置格式错误无法加载的问题。 > xml+``的方式可能配置上更加灵活，不需要通过java代码直接操作appender，但是无形增加了配置的复杂度，使logback配置文件看起来非常臃肿不好理解。 listener方式虽然配置不灵活，但是对日志掌控权高，可以规范日志采集的一些关键配置。 总的来说两种方式各有优劣，大家一起讨论一下，选择一个合适方式来管理日志采集功能

我最新的一次pr按照listener思路重新弄了一下，实现的思路和Springboot集成logback类似，如果用户xml添加了appender按照用户的xml配置为准，如果没有配置加载seata默认appender，并且透出自定义配置项供用户在yml中维护

> appender这些可以先不用继承方式来做吧？ 是的，现在还没有使用继承的方式来做，只是所有的appender都采用LoggingEventCompositeJsonEncoder来处理json转义，保证不会出现msg转义问题。 之前代码的appender类主要是指将appender添加到loggerContext，可能命名存在歧义，现在已经修改命名方式为AppenderProvider结尾，使用appendTo方法向loggerContext添加appender

我简单说一下当前的实现思路，当前实现的主要思路是当LoggingExtendApplicationListener监听到ApplicationEnvironmentPreparedEvent事件时，会实例化LogbackExtendConfigurator对象并且调用其中的doLoggingExtendConfiguration方法。 LogbackExtendConfigurator首先向loggerContext加载一些必要的配置信息，然后会通过seata SPI机制，获取所有实现LogbackLoggingExtendAppenderProvider的实现，调用其appendTo()方法，完成appender配置并添加到loggerContext中，。 其中涉及到的主要类及其关联关系如下：