先声明，此文不一定对大家伙有用，只是一个问题查找过程记录下罢了。

事情是这样的，在一次由spring-task改造为elastic-job需求中，经历了一件很郁闷的事情。
elastic-job部分配置是这样的，很简单，elastic-job的部分配置

<reg:zookeeper id="regCenter" server-lists="${GAC_JOB_URL}"
                   namespace="${namespace}" base-sleep-time-milliseconds="1000"
                   max-sleep-time-milliseconds="3000" max-retries="3" />

然后在properties里面，我们就叫它xxx.properties加入HAC_JOB_URL=10.x.xx.xxx:2181
指定-Dspring.profiles.active=uat后，按道理应该是很顺利的将${HAC_JOB_URL}替换为上面的字符串的，可是奇葩的事情就是发生了，报错了：

java.net.UnknownHostException: ${HAC_JOB_URL}: unknown error

居然告诉我不解析就直接打印错误出来？没办法只能一头扎进去找原因，找找找。。。。

开始以为是elastic-job的配置问题，自己不熟没办法。。然后就各种改配置，最郁闷的是，另外一个工程也是从spring-task改造为elastic-job，但是它居然能跑起来，还跑的很high…
好吧，可能是我哪里错了，于是我就按照它来改了一把，还是不行，还是一样的错误，此时已经很晚了，本来想18点下班回家陪老婆吃饭的，都泡汤了，尝试修改各种配置，结果都是一样，时间来到了晚上21:40，算了，还是回家吧，要不然被老婆骂了。
在回家路上，我突然想到，为什么不在本地跑一下，因为之前都是修改代码立马提交，jenkins负责构建。
第二天一大早来了到了办公室，打开电脑，本地跑起来，居然能正常启动，没有重现之前在回归环境下的问题，我开始怀疑是不是构建脚本有问题了，但是又没证据，不能拖运维同学下水，只好继续定位原因。
我开始比较两个环境的日志，突然发现我本地明显多输出了一些properties的key和value，多出来的恰恰是xxx.properties中新增的HAC_JOB_URL，于是，我把这个key配置到另外一个properties文件里面（我们有几个这种文件，这样好区分-_-），提交重新触发jenkins构建，xxx，这次居然成功了，跑起来了，我泪流满面。很明显，在那个文件里面添加新的key是没有任何作用的，但是为什么没用呢？

我把Jenkins构建好的包打开来看，发现一个问题，就是xxx.properties文件不管你怎么改，只要构建完它最后都会固定生成一个文件，里面的内容是永远不变的。好吧，真相大白了吧？ 于是我把这个问题抛给了运维同学，运维说没有xxx.properties这个文件。好吧，我继续找原因。

我想竟然是每次构建后才覆盖掉项目中的xxx.properties，那么可以从构建脚本入手，于是我打开jenkins构建日志，果然看到了一条这样的记录：

scp -r /root/.jenkins/profile/jds-efg/xxx.properties [email protected]:/usr/local/software/abc-efg-app-tomcat/webapps/abdandaj/WEB-INF/classes/properties/uat

另外一个可以成功启动的项目输出是下面这样子的：

scp -r /root/.jenkins/profile/jds-efg-app/xxx.properties [email protected]:/usr/local/software/abc-efg-app-tomcat/webapps/abdandaj/WEB-INF/classes/properties/uat

两个唯一的区别就是下面的多了一个-app，也就是说，第一个拿的不是项目中最新的，而是/root/.jenkins/profile/jds-efg/xxx.properties目录下的，很久之前的，这也是为什么每次构建完都会被覆盖的原因。
最后让运维改了构建脚本就可以正常启动了。

这次是由于运维同学大意写错脚本导致的，可能对大家没什么实用价值，只是想到这次定位问题的过程，就做个记录下，毕竟连陪老婆吃饭都泡汤了哇，不过话说回来哪天真的有人犯一样的错也说不定呢，嘿嘿(^▽)