Eclipse中Resin插件部署使用

          Eclipse对Resin的插件支持远不如Tomcat等插件。如果使用Resin插件部署项目到Resin。形如下图：

          在Tomcat中做到这一步再改下一下server.xml中对应项目的reloadable=false。热部署环境就已经完成了。但如果你对Resin做这样的操作就属于南辕北辙了。接下来看一下插件对Resin的发布操作。

          拷贝了一个war过去。服务免不了要解压重启。这离热部署相距甚远。对于开发来说不需要打包这个动作。只要能把资料发布上去就可以了。

          第一种方式，我尝试让Resin直接指定Eclipse的发布目录（org.eclipse.wst.server.core）里的tmp0。但在发布的时候目录被锁住了。然后我就开始修改Resin的buildfiles脚本。如下：

          我自定义了一个发布目录来取代webapps目录。如何把所有文件拷贝非覆盖方式发布过去。最后在resin.conf文件中用绝对路径指向自定义的发布目录。关掉自动发布。Resin禁止自动加载redeploy-mode="manual"，此配置跟Tomcat的reloadable="false"的意图一致。

          这种方式基本上模拟了Tomcat用户的操作习惯。

          第二种方式更为简便。针对的是jar包改动不频繁的。这种方式我称之为“strange”模式。因为服务器看上去根本没有加载项目。只是在resin.conf文件中用绝对路径指向了发布路径。而且指向的发布路径就是源代码的WebContent目录。然后Eclipse中将原来在build目录生成的class文件转向了WebContent/WEB-INF/classes目录下。这样可以人为的将开发和发布目录合二为一，很巧妙。但这种方式对工程间存在依赖关系的不适用。因为子工程是作为jar方式加入父工程的lib下面而非class目录。所以如果工程存在依赖关系的话还是用第一种方式更适合。

          后记：关于Resin4.0配置

          首先，Resin4.0增加了很多配置文件。加强了集群的概念。

          主要的变量写在了resin.properties文件里（resin.xml文件中的值会被里面的覆盖）。看一下他自己是怎么说的。

          其他文件里的所有${...}形式的变量都在这个文件里被定义。以简单值对的方式存在。

          然后其他文件中会有一堆的判定式进行对Resin进行配置。

          这种方式还好吧。只要英文没有太烂就不会将部署项目写在其他的判断条件里。剩下的就是开发的工作了。Resin的认识告一段落。