在一次项目上线后，发现了一个奇怪的问题，经过对源码的阅读调试终于解决，具体经过是这样的：

问题描述：tomcat7下面部署多个项目，log4j的日志输出会集中输出到一个项目中，就算配置了日志文件的绝对路径也是一样的。

解决方法：log4j.jar在每个项目中单独加到lib下

解决过程：先从log4j入手分析，在项目启动时调试org.apache.log4j.FileAppender,输出获取文件路径是绝对路径，应该是没有问题的,其实在正常的启动下也会输出该日志
信息: Set web app root system property: 'RootPath' = [H:\Project\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\wtpwebapps\cpa-1.0\]
信息: Set web app root system property: 'CpaRootPath' = [H:\Project\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\wtpwebapps\cpa\]
log4j是基于spring进行初始化的，到这里怀疑是spring容器实例化作用域是否有问题，但是本地调试又正常的，发布到tomcat才有问题，好奇看了一下之前的部署的项目，发现日志是没有影响的；

　　调试log4j的初始化源码，使用PropertyConfigurator.configure(configFilename)进行初始化测试，日志的输出路径配置会被addAppender到LogManager.getLoggerRepository()实例的repositorySelector变量中，而LogManager中的repositorySelector是静态初始化的；当然到目前为止仍然不会有问题，关键是tomcat的jar共享，放在shared/lib下面的共享包会被URLClassLoader加载，单独放到项目lib下面的jar包会被WebAppClassLoader加载，区别就在这里，关于URLClassLoader和WebAppClassLoader加载为什么会引起这种问题还要继续深入分析tomcat启动加载。

　　了解Java和JVM的一定知道，JVM中通常有三层默认的类加载器，分别是启动（Bootstrap）类加载器、标准扩展（Extension）类加载器和系统（System）类加载器。这三者每两者间都是父子关系，即前者是后者的父亲或者双亲类加载器，并由此构建了一个“双亲委派关系”，或叫“代理”关系。当Java虚拟机要加载一个类时，到底派出哪个类加载器去加载呢？

• 首先当前线程的类加载器去加载线程中的第一个类（假设为类A）。

　　　　注：当前线程的类加载器可以通过Thread类的getContextClassLoader()获得，也可以通过setContextClassLoader()自己设置类加载器。

• 如果类A中引用了类B，Java虚拟机将使用加载类A的类加载器去加载类B。
• 还可以直接调用ClassLoader.loadClass()方法来指定某个类加载器去加载某个类。

　　上面是jvm加载class的加载器，当tomcat启动时会为每个app分配了一个WebappClassLoader ，这样来避免多个app会加载相同jar包的问题，WebappLoader的parent是org.apache.catalina.loader.WebappClassLoaderBase，细看源码WebappClassLoaderBase直接继承于java.net.URLClassLoader类，最终继承于java.lang.ClassLoader类这样多个app就能共享tomcat的类库；WebappClassLoader的源码中发现，在进行findClass时会先试图自己加载类，找不到则请求parent来加载，这里和java的双亲委托模式是不同的，所以如果log4j放到项目lib下面会被当前项目的WebAppClassLoader加载并初始化静态实例，因为每个项目都被单独分配了WebAppClassLoader，这样jvm就能区分来自不同项目的各个类（热部署使用的就是该技术）。

总结：如果不深入的了解jvm和tomcat类加载器是很理解该问题是如何解决的，经过分析源码，并写了demo进行测试才实践出上述结论，实践出真理！