梦想风暴

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://dreamhead.blogbus.com/logs/72034.html

有没有压力的感觉果然不一样。

经过近乎疯狂的编码，项目顺利拿出手，一根紧绷了近一个月的弦一下子松了下来。这两天感觉整个人特别懒散，什么都不想干，就连blog都懒得写了。

在我们传统的开发方式中，比如用C/C++，我们会把自己应用的所有东西放到自己应用的目录下，比如bin下放可执行文件，conf下放配置。通常顶层目录则是由我们任意指定。
对于J2EE部署，我的认识基本上是，把所有class和部署描述符打成一个包，可能是EAR、可能是WAR，然后部署到应用服务器上。一般部署的结果就是放到了应用服务器的目录上。
这是我脑子里一直难以解开的一个结，我们无法按照传统的方式部署我们的应用。

我们的新系统中，一个同事创造性的解决了这个问题，使我们按照传统的方式部署我们的应用。具体做法很简单：部署时，只把描述符部署到应用服务器上。而我们应用的class文件打成一个JAR文件，把它配置到应用服务器的classpath中。至于可能用到JAR文件，我们也不像原来一样打入应用的包中，而是单独部署，放到我们应用的lib下，然后也是配置到应用服务器的classpath中。至于配置，程序会读一个环境变量确定配置文件的位置，于是配置文件的位置也成了可配的。

由此，我们的应用彻底与应用服务器分开，我们可以按照传统的方式组织自己的应用。

或许从表面上并不能看出这种做法的好处，如果你能够亲身经历一次打包发布的漫长煎熬，现在这种只要自己手工就可以简单完成打包，发布变成了一个FTP的过程，估计就能体会我们用这种方法的幸福。另外，我们的实施人员更习惯于原本的那种部署方式，而并非J2EE那种一切尽在应用服务器的方式。

最初接触到这种做法，我惊讶的嘴都合不上了，太精妙了。回过头来想想，其实这只是一个惯性思维的问题，太过于习惯现有的东西，有些很好的解决办法其实只要简单的转化一下思路就OK了。

突然想起前不久调系统的一个bug，费了好大的劲，最终的bug是出在一个已经用了几个月的类上。这是一个读XML配置文件的类，现在的系统用了多个配置文件，一读就错。最终发现一个成员被写成了静态的，所以第二加载的时候会覆盖掉第一个，之所以以前没错，因为以前只有一个配置文件。

调这个bug费了好大的劲并不是因为这个bug如何之难以找到，关键是因为我根本没有想到这个类会错，因为它已经是我多次维护过，并且稳定运行了好长一段时间了。这还是一个惯性思维的问题。

偶尔跳出三界外，一片海阔天空。