当用Spring的当用ClassPathXmlApplicationContext获取应用上下文时。有两种方法。
FileSystemXmlApplicationContext引用的是具体文件系统的文件路径,而ClassPathXmlApplicationContext
在classpath找到xml文件
刚开始使用的是用Maven所构建的web项目。当前项目位于G:/newtool/workspace/springmvc中
knight.xml是放在src/main/java中。如果放到了src/main/java/di中,构造参数应该传入"di/knight.xml"
不然是找不到文件的。
先看看maven创建的标准的目录布局:
Introduction to the Standard Directory Layout
src/main/java/ 源文件
src/main/resources 资源文件
但是如果把knight.xml放到src/main/resources中时,并不需要构造参数应该传入"src/main/resourcesres/knight.xml"
而是直接传入"knight.xml"。
这里就会意识到问题了,这样看的话,我们要先找出classpath是哪里。
打印出来的包含G:/newtool/workspace/springmvc
还有就是bulid path还有classpath。
建议先看下两个问题回答,我翻译一些很好的解释。
http://stackoverflow.com/questions/12893760/spring-cannot-find-bean-xml-configuration-file-when-it-does-exist
http://stackoverflow.com/questions/3529459/what-is-the-difference-between-class-path-and-build-path
先说classpath,classpath会告诉java编译器还有运行时去找的编译好的class。典型的是JAR文件名称还有目录的一个序列。
Build path并不是java的术语,它用来构建应用,包含编译该应用的所有源文件和java库。
IDE通过这个配置classpath和sourcepath。
所以,我run的时候,发现xml放在src/main/resources也好,放在src/main/java也好。
其实现在我们用惯了IDE之后忽略了一个问题。就是运行前还有进行一些操作的时候,
IDE都帮你重新构建项目了,所以放到这两个目录里面。
将run的配置设置成运行前不自动build。然后手动删除
G:/newtool/workspace/springmvc目录下的xml文件,便会出现找不到xml的错误了。
前面我们是用了Maven构建,我们如果用Dynamic Web Project的时候。
classpath是在G:\newtool\workspace\SpringMVCweb\build\classes类似这样的目录下面的。
所以具体的还是在Eclipse这边控制。
至于后面使用:
为什么没有改变到classpath,xml还是正常加载到。
如果build是编译的话,和最原始的javac又有什么区别呢?
因为是从英语的思维去思考的,还有这些纠结几个英文单词的话,中文很难找到答案。所以这次自己是自己在Stackoverflow提了自己第一个英文问题。虽然英文写的蹩脚。
http://stackoverflow.com/questions/39585055/whats-the-differences-between-the-build-function-of-eclipse-and-javac
最后的到了答案,好感谢这位德国朋友。
更改的JVM的classpath并不是当前运行的,所以现在正在编译运行的还是原来的目录。
所以xml还是正常找到。所以并影响到的是新的加载器,如果要想这样,我们需要去用这个加载器去重新加载
整个spring的东西。确实这个真正相关的是Eclipse本身类加载器的一些配置上面了。追根到底的话。
不知道我为什么会问这种这么理论的问题,不过偶尔思考下问题也是好的。