调试总结：Ant,CLASSPATH,Runtime.exec() & ultraedit

调到新项目组后部署环境，遇到了不少有趣的问题，这里记录一下。

Server端的程序用ant部署。装了oc4j后，从clear case上拖下了程序，跑ant的过程中发现oc4j在ant里起不来，错误是errorcode=3, Java的IOException。手动到oc4j的home/j2ee下敲java -jar oc4j.jar是好的，怎么回事呢？打开build.xml看了看也没错，单独跑start_oc4j的task还是一样的错误。以前没用过ant,想了想这应该不是ant的bug吧——如果是绝对是个major的bug，早该有人发现了。

想一想，ant基于java，应该是用runtime.exec方法去实现的，由于这个task里面牵涉到dir参数，自己写了个模拟的java实现测了一下 

 

public   class  Test ... {
    public static void main(String[] args)...{
         Runtime.exec("hello.exe",null,new File("f://");
    }
}

 

这里hello.exe是用c#写的一个console application, Main方法为System.Console.Write("Hello");编译好的hello.exe放在f盘根目录。本来想直接调cmd.exe，不过那玩意设在路径里，就判断不出exec的第三个参数dir是否有用了。在eclipse里跑这个Hello程序，结果居然都报错...汗！想想看还是路径问题，考虑到IDE把路径什么都封装了，干脆咱到command line下试试吧。

到了目录下先javac Hello.java, bingo！再来Java Hello,结果居然是 ClassNotFoundException~~，瀑布汗！这好像是Java入门教材中的例子，当年教java时都拿这个考人的，怎么今天这么邪门？仔细检查了main函数的签名，public static void main(String[] args)一点不差，也没有因为前段时间敲c#给写成Main，这下真没辙了。老老实实google了一下，发现自己原来犯了好大的错误，混淆了OS和Java搜寻的路径。

在OS下敲一个命令，搜索的顺序是当前目录,PATH指定的目录。而java仅仅在CLASSPATH指定的路径中寻找.class文件，而不会到当前目录中去寻找。所以虽然Hello.class就放在当前目录，由于我在windows的CLASSPATH中没有当前目录".;"（天知道我什么时候删掉的），所以java就找不到Hello.class了。而Eclipse在跑的时候其实指定了java -CLASSPATH,其中包含".;"所以IDE能跑，而我不能。修改了环境变量后，java Hello就能跑起来了。

虽然能跑，Runtime.exec还是报错。将其修改成

 

Runtime.exec( " f:/hello.exe " , null , new  File( " f:// " );

后倒是能跑，可为什么第一个版本中指定的working directory不起作用呢？继续google，搜出了N多讲通过cmd.exe调用dir的帖子，筛来筛去总算找到了一个帖子，说exec的dir参数指定的是working directory，而不是current  directory，要调用不在系统PATH里的程序要在第二个参数envp中额外指定PATH。按照他说的方法试试了，外甥打灯笼——照旧。到最后也没找到答案，只是以后还是敲绝对路径吧。

再回到ant中来， 盯着出错信息看了半天  c:/jdk1.4.2.03/bin/java.exe -jar oc4j.jar -....这样一句就是不能执行，太郁闷了。干脆复制下来到command line试试，一试之下，还是错！不过出错信息已经很好理解了，找不到java.exe。一看ant的properties,JDK_HOME赫然是c:/jdk1.4.2.03/bin/ ，而我的jdk应该是c:/jdk1.4.2/bin/ ，修改properties文件时没注意到多了".03"，而ant前面的task都没有用到JDK_HOME这个property，所以昨天一天调前面task时都没报错，残念啊～～～

改过JDK_HOME后总算ant完成了，可在maxthon里面敲http://localhost:8888有反映，而敲http://localhost:8888/WOS/GateInService就会报404，那么服务到底发出来没有？最好的方法就是用客户端来连本机的oc4j看看能否连上。拷来一个dev的client端，用ultraedit将webserviceconfig.xml中webservice地址都替换成localhost:8888，保存，启动——CRL错误！我靠！

找client的developer问问，说是要装.Net Framework1.1，我想机子上都装了.Net Framework 2.0了，应该不是这个问题吧？死马当活马医，装了1.1，还是不行。又下了个安装版本，还是有问题，彻底傻了。

把窗口都关掉，重启windows，居然好了。脑后一阵凉风，忍不住有了灵异的感觉。用ultraedit把URL替换了，再跑，还是错！

慢着，慢着，好像看出点问题了。把ultraedit关了再试试，好了。那么问题究竟出在什么地方呢？打开ultraedit的option一个个看，我之前曾经设置过的东西只有“不生成.bak文件”，果然是这个问题。连起来想想，整个事情的缘由是这样的：

ultraedit缺省会生成.bak文件，这样对于原文件是以读方式打开的。而设置不生成.bak文件后，在打开文件时加了写锁，原意大概是防止其它进程的误操作。偏偏c#的客户端程序也要以写方式打开这个文件（不知道为什么？）来读配置，这样IO会报错。偏偏这个Exception被CLR拦住后以粗暴的方式报了出来，让人很费解。用户在使用程序时不会去锁这个文件，所以不会发现这个问题。其它的developer虽然会开着ultraedit编辑，但都是缺省的生成.bak文件，所以也不会遇到这问题。只有我这种具有破坏性的操作下，才遇到了这个问题。

总的来说，今天遇到的问题本身并不复杂。但在深入追究问题的过程中，还是学到了不少东西。

PS:回家后又试了下家里的ultraedit13.10a+1，已经不存在这个问题了。看来还是公司正版的老版本有问题。而在IE里面是可以直接访问到部署的webservice的，不能访问是maxthon有问题（不知道是不是我设置的不对）。