看了网上的众说纷纭，发现到了我这没有一个好使的处理方法，不过我自己搞了一两天，自己搞出个和他们都太一样的。
先来个错误信息的关键字
警告: [SetContextPropertiesRule]{Context} Setting property ‘source‘ to ‘org.eclipse.jst.jee.server:org.joven.foundation.utils‘ did not find a matching property.
有人说在处理的时候将代码的发布路径改了改到webapps下面，我想说的是既然tomcat支持发布到其他路径下面，肯定是为了方便开发的人员进行维护，为何非要重复以前的路非要发布到老的目录下呢？
我非常的不信邪，于是就偏偏发布到wtpwebapps下。
接下里看这个位置，看到网上想必大家也发现了都是说的publish module contexts to separeate xml files 这个是不是要勾选
1、先看不勾选时，怎么办才会不报错
不勾选时大家相比大家知道在eclipse中的service.xml文件会拷贝到tomcat的config下的service.xml中内容完全不差异
这是我们会发现这个source也是会拷过去的，这是要是就去启动tomcat的话对不起那个错还是会有的，这时我们可以手动到tomcat的service.xml中将这个属性干掉，同时手动改一下docBase（不改的话tomcat会去webapps下查找，找不到就报错了，当然也是可以在eclipse中写好的），在启动就不没有了。
优点：代码发布到的了自己想要的目录，方便后面的调试管理
缺点：若是开发的过程中对tomcat进行了publish则需要从新检查配置
若是想在eclipse就该好，对不起这是就只能将代码发布到的webapps下才会ok，（这种不符合我的要求，知道可以也没有采用，有兴趣的可以试试）
2、再看勾选时，怎么办才会不报错
勾选了之后会发现在tomcat的service.xml中不再有我们的<Context docBase。。。> 部分，这部分被单独的提了出来，位置在同级文件夹下Catalina/localhost下的文件，文件名为工程名.xml
仔细看里面的文件就会发现这个是单独的，不知道是不是这样好维护，目前还没有体验到。
打开这个文件就会发现那个阴魂不散的source还是跟来了，这时直接再干掉它就好。
优点：代码发布到的了自己想要的目录，方便后面的调试管理
缺点：若是开发的过程中对tomcat进行了publish则需要从新检查配置
0、到此算是暂时解决了启动不报这个错了，唯一的缺憾是不管这俩方法怎么搞，每次的publish后都要手动改一下
欢迎评论斧正！
注：本人使用的tomcat9 + jdk 8 + jee eclipse
eclipse下启动tomcat9出现Setting property 'source' to 'org.eclipse.jst.jee.server:
原文地址：https://www.cnblogs.com/can44/p/10204948.html