logback的xml配置文件没有DTD或者schema，也就是说可以让人随意的配置

结果就是，一不小心就会配置一些错误的标签进去。或者是原来的配置是正确的，但是logback升级等操作之后，配置就会有错误了

如果在一般的application（war其实也是某种格式的application）当中，即便是用来spring作为容器，但是main方法是完全Pure Java的，即自己手动的加载Spring的Application Context，这时候触发logback的加载，一旦有错误发送，会在Console输出ERROR信息，但是很可能不影响后续启动。如果不细心观察，很可能认为启动当中没有异常。

出现这个现象的原因，大概是Logback认为自己即便启动当中有错误，也就是影响到日志的一些输出，况且可能输出都不会受影响，所以就对着Error听之任之了。

但是一旦使用其他的启动方式，结果就不太一样了。比如使用spring boot启动。由于spring boot采用了自己的logback的加载器，一旦logback加载过程出现异常，Spring boot会抛出异常，中断启动过程。同时报错logback配置有误。

两个一对比，就会产生一个误判——认为曾经正常配置的xml在spring boot中不能用了。可能误判为jar冲突之类的错误。

即便是exclude了spring boot自带的logback相关的jar，也会报这个错误。

最后把原来可以运行的application启动，发现了logback的Error，这才找到了原因。

Spring Boot对于这类Error没有放过，直接终止了。

结论：有时候一些不是很Fatal的Error可能会被放过，但是一旦启动过程报错，十有八九就是配置之类的真的有错了。最好把原来能够启动的application启动一次，仔细看看输出再做判断。