关闭

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

1354人阅读 评论(0) 收藏 举报

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

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有问题(不知道是不是我设置的不对)。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:6354次
    • 积分:138
    • 等级:
    • 排名:千里之外
    • 原创:7篇
    • 转载:0篇
    • 译文:0篇
    • 评论:0条
    文章存档