前几天来了个小任务，把某项目中某人的邮件地址改了下。

由于对项目不熟悉，于是采用find方式找出app中所有包含某人邮件地址的文件都找出来了。

xml，properties大约三四个，还有两个class。

当时也没想太多，把class像xml一样用VI改了，心想改的是可见文本，应该问题不大，然后重启tomcat。也没测试一下。

今天打开发布在tomcat上的url，发现打不开了，心想应该是修改class导致的。到tomcat_home的logs文件夹下一看，还真是那两个类出错了，而且当时没留下备份，当时那刻还是挺慌的。

于马上翻文档，终于从SVN上下载了当时代码，三年前的，当年的工具也没有，还好Java代码是全的，于是用MyEclipse新作工程，再导入需要的包，修改文本值，还好，class顺利编写出来了。

再FTP登录，用新class替换老class，重启TOMCAT，项目如愿跑起来了，这下子真正清楚，为啥很多文章反复强调一定要把配置信息写到xml或是properties文件里面了。对开发团队来说，也许修改XML和JAVA是同样的工作量，但是对运维团队就大不一样了。

有应急预案，冷静沉着应对问题是今天没出岔子的关键。

这件小事得到两个教训：1.修改文件前必须先备份好；2.class文件必须是编译的版本，不能是修改的。如果大不幸没有源码，只要反编译，修改得到的Java，再编译回去。

于是记之，希望对遇到同样问题的人有所帮助。