秘密1：
在plugin-cfg.xml中，application context root的搜索为自下而上。一旦搜索到目标，立即停止，即使同样的context root在plugin-cfg.xml文件中不止一个。
实例解析（以下代码处于同一Plugin-cfg.xml文件中）：
从上可见，ContextRoot同为gpa的情况下，在plugin-cfg.xml文件中有两个URIGROUP与之对应。但是，当用户通过web http server加上ContextRoot gpa访问时，websphere plugin只会（注意是“只会"）定位到URIGROUP default_host_IPAServer_agaisg70v61act_Cluster_URIs，因为它处于所有gpa的最下方。而且，搜索到后立即停止，不会再去寻找其它匹配的URIGROUP，不管搜索到的gpa所对应的application server是开启还是关闭的状态。
所以称其为“自下而上”的搜索。
秘密2：
在plugin-cfg.xml文件中，可通过手工编辑ServerCluster元素来添加和删除其包括的Server标签成员。
实例解析：
产生的plugin-cfg.xml文件中，我们都会看到类似于如下的元素标签：
其中，一个ServerCluster标签中存在一个Server元素。我们可以手工添加另一个server元素到这个ServerCluster之下，如下所示：
我们添加了一新server标签。如此一来，ServerCluster内就有两个server，可以实现对request的分流，模拟出一个cluster环境来（注意是“模拟”），即使这两个server成员在websphere application server端不是在同一个cluster内。
这时，肯定有网友质疑这个秘密有何用？因为完全可以通过WDM建立Cluster，然后产生相应的plugin-cfg.xml文件，其中ServeCluster内就自动包括了多个sever元素。的确如此！但是，有些application的需求就比较奇怪另类。Application不允许建立在cluster的环境底下，因为cluster的某些特性会影响application的正常运行。然而，同样的application却需要部署在多个WASNode的application server上，而且彼此之间能够实现负载均衡。也就是说，需要application在non-cluster的情况下犹如运行在cluster中（有点拗口），类似于实现load balance的功能。对于这种特殊需求，我们就可以通过以上手工编辑的方法来实现。
欢迎各位网友一起讨论研究。
收起