解決方法一：用“注銷”方式退出遠程桌面，而不是直接關閉窗口；

解決方法二：踢出已經斷開的連接用戶；

1、首先通過各種方法連接到服務器上（telnet）；

2、上去后，查看登陸用戶列表。輸入命令：query user；

這樣你就可以看出有何不同來啦，可以根據你的具體情況而定的。ID為0的用戶就是本地登陸的，而在State中看提示，當提示為已斷開，則說明用戶已經斷開還占用著系統資源和通道，這樣就可以把該用戶踢掉。輸入logoff ID，即踢除相應ID的用戶。

解決方法三：限制已斷開連接的會話存在時間；（推薦）

一般情況下，我們在維護遠程服務器時，不可能長時間在線，但是系統默認的卻是只要登錄就不再斷開。因此，我們可以修改這一默認設置，給它指定一個自動斷開的時間即可。

可以在 Windows 2003 服務器上通過組策略中設置一下來解決問題：單擊“開始 → 運行”，輸入“gpedit.msc”，回車后打開組策略窗口，然后依次定位到“計算機配置 → 管理模板 → Windows 組件 → 終端服務 → 會話”，然后在右側窗口中雙擊“為斷開的會話設置時間限制”，在打開的窗口中將“結束斷開連接的會話”時間設置為5分鐘，或者設置為空閑就斷開。或在遠程服務器上打開“運行”窗口，輸入“tscc.msc”連接設置窗口。然后雙擊“連接”項右側的“RDP-Tcp”，切換到“會話”標簽，選中“替代用戶設置”選項，再給“結束已斷開的會話”設置一個合適的時間即可。

解決方法四：增加連接數量，即設置最大連接數再多些；

默認情況下允許遠程終端連接的數量是2個用戶，我們可以根據需要適當增加遠程連接同時在線的用戶數。

單擊“開始→運行”，輸入 “gpedit.msc”打開組策略編輯器窗口，依次定位到“計算機配置 → 管理模板 → Windows 組件 → 終端服務”，再雙擊右側的“限制連接數量”，將其TS允許的最大連接數設置大一些即可。

經過上面兩個配置（方法三&方法四），基本上就可以保證遠程終端連接時不再受限。但仍有人反映，當前同時只有一個用戶進行連接，卻提示超出最大允許鏈接數，這又是什么原因呢？出現這種情況是因為操作不當所造成的。在上一個帳戶登錄遠程桌面后退出時，沒有采用注銷的方式，而是直接關閉遠程桌面窗口，那么導致該會話并沒有被釋放，而是繼續保留在服務器端，占用了連接數，這樣就會影響下一個用戶的正常登錄了。

解決方法五：限制用戶會話數；

對Terminal Services進行限制，使得一個用戶僅僅能夠連接一次。對于Windows Server 2003，請在Terminal Services Configuration（Terminal Services配置）中將“限制每位用戶只有擁有一個會話”（Restrict each user to one session）設置為“是”（Yes）。此外，您可以將“限制終端服務用戶使用單個遠程會話”組策略設置為“啟用”。

注意：版本不一樣解決的方法有異！

A：這是因為Windows 2003中設置了最大允許連接數限制，而你每次連接后可能沒有注銷而是直接關閉，導致連接數超過了最大連接數。你可以在Windows 2003 服務器上通過組策略中設置一下來解決問題：單擊“開始→運行”，輸入 “gpedit.msc”，回車后打開組策略窗口，然后依次定位到“計算機配置 → 管理模板 → 終端服務 → 會話”，然后在右側窗口中雙擊“為斷開的會話設置時 間限制”，在打開的窗口中將“結束斷開連接的會話”時間設置為5分鐘。最好的解決方法還是你每次斷開連接時通過注銷的方式。

B：經常多人管理服務器的朋友一定遇到過當自己終端連接遠程計算機的時候卻提示“終端連接超出了最大連接”的提示吧？這是因為windows2003僅支持2個終端用戶的登陸。當這種情況出現后，多數人選擇的是給機房打電話進行重啟服務器。可是帶來的損失也是顯而 易見的。那么我們有什么辦法來解決呢？方法當然是有的。我們只需要在一臺2003的機器上運行“tsmmc.msc”就可以打開遠程桌面連接，在這里我們 添加一個新的連接，輸入對方的IP地址帳號和密碼后就可以成功登陸到對方的桌面中，這時可以再踢下一個用戶。就可以解決終端連接數超過最大的問題。

C：開始 → 控制面版 → 授權里面更改連接數。

在命令行：
mstsc /console /v:你的服務器IP:遠程端口

例如 :mstsc /console /v:222.222.215.222:3389

win2K/win2003終端服務器超出最大允許連接數解決之道全攻略
原因:用遠程桌面鏈接登錄到終端服務器時經常會遇到“終端服務器超出最大允許鏈接數”諸如此類錯誤導致無法正常登錄終端服務器，引起該問題的原因在于終端服務的缺省鏈接數為2個鏈接，并且當登錄遠程桌面后如果不是采用注銷方式退出，而是直接關閉遠程桌面窗口，那么實際上會話并沒有釋放掉，而是繼續保留在服務器端，這樣就會占用總的鏈接數，當這個數量達到最大允許值時就會出現上面的提示。
如何避免？
一、用注銷來退出遠程桌面而不是直接關閉窗口二、限制已斷開鏈接的會話存在時間
1、從終端服務配置中修改
運行－Tscc.msc(終端服務配置)－連接－雙擊RDP-Tcp或右擊－屬性－會話－選中第一個的替代用戶設置(O)－結束已斷開的會話［將默認值“從不”改為一個適當的時間，比如30分鐘］
2、從組策略修改
開始－運行－gpedit.msc－計算機配置－管理模板－windows組件－終端服務－會話
右邊窗口選擇 為斷開的會話設置時間限制 －選擇已啟用，選擇一個時間
三、增加最多鏈接數
1、從終端服務配置中修改：運行－Tscc.msc(終端服務配置)－連接－雙擊RDP-Tcp或右擊－屬性，選擇“網卡”選項卡－修改“最大連接數”改成你所需的值，當然這個值不也能太大，否則會占用較多的系統資源。不過這里修改的值好像不起作用，設置成無限制時照樣還是會出現本文所說的情況。  
2、組策略級別要高于終端服務配置，當啟用組策略后終端服務配置中的相應選項會變成灰色不可修改
運行－gpedit.msc－計算機配置－管理模板－Windows組件－終端服務
雙擊右邊的”限制連接數量“－選擇”已啟用“－填入允許的最大連接數
四、改變遠程終端模式
打開“控制面板”，雙擊“添加刪除程序”，單擊“添加刪除Windows組件”,“組件”，在Windows組件向導對話框中選中“終端服務” , “下一步”,“應用服務器”,“下一步”，然后按照提示即可改變終端服務的模式。  
Windows 2000終端服務有2種運行模式: 遠程管理模式和應用程序服務器模式。遠程管理模式允許系統管理員遠程管理服務器，而且只允許2個終端會話同時登錄終端服務器。應用程序服務器模式允許用戶運行一個以上應用程序，允許多個用戶從終端登錄訪問服務器。但是，應用終端服務的用戶必須有終端服務授權，即必須在90天之內在這個域或工作組中設置終端服務授權服務器，否則用戶需刪除應用程序，然后再重新安裝。
五、修改本地安全策略
控制面板>>管理工具>>本地安全策略>>本地策略>>安全選項>>
1、先找到>>Microsoft網絡服務器:在掛起會話之前所需的空閑時間
默認為:15分鐘,改為自己所需要的時間(就是登陸后無動作空閑超過多少時間后自動斷開)
2、然后找到>>網絡安全:在超過登錄時間后強制注銷。默認為:已禁用,一定要改為:已啟用
如果已經發生解決辦法：
1、首先你可以telnet到此主機上(不管你用哪種方法)，當然如果能直接操作機器更好，不過直接操作就不必用命令行了，那當然是知道機器超級管理員的密碼的情況下，可以使用OpenTelnet來打開遠程服務器的Telnet端口。
2、Telnet上去后,先看登陸的用戶：
輸入命令：query user
系統返回：
C:>query user
USERNAME        SESSIONNAME     ID    STATE     IDLE TIME    LOGON TIME
k12update       console         1     運行中         2007-3-14 14:57
此時可以看出的可能都不一樣，根據具體情況而定。
ID 0 的用戶是本地登陸的,ID 1 和 ID 12是3389登陸的用戶,前者在運行中，后者已經斷開了,但是斷開了仍然占用系統資源和通道，我們要把它踢掉。如下進行操作即可。
輸入命令：logoff 1
3、如果服務器關閉了telnet功能（這是默認的），還可以通過SqlServer的xp_cmdshell擴展存儲過程，使用格式：master.dbo.xp_cmdshell '命令內容'，其余可參考第二步。此方式要求有訪問xp_cmdshell的權限
上面的辦法基本沒有用

[原創經典]“終端服務器超出了最大允許連接數”的解決辦法

2007-04-25 17:13

現象及原因：用遠程桌面連接登錄到終端服務器時經常會遇到“終端服務器超出最大允許連接數”諸如此類錯誤導致無法正常登錄終端服務器，引起該問題的原因在于Windows Server 2003中設置終端服務的缺省連接數為2個鏈接，并且當登錄遠程桌面后如果不是采用注銷方式退出，而是直接關閉遠程桌面窗口，那么實際上會話并沒有釋放掉，而是繼續保留在服務器端，這樣就會占用總的鏈接數，當這個數量達到最大允許值時就會出現上面的提示。
解決方案：
法一：用“注銷”方式退出遠程桌面而不是直接關閉窗口
法二：踢出已經斷開連接的用戶
1、首先telnet到此主機上(不管你用什么方法)，當然如果能直接操作機器更好，不過直接操作就不必用命令行了，用控制臺更直觀(略過)。
2、Telnet上去后,先看登陸的用戶：
輸入命令：query user 系統返回：
用戶名Username      會話名Session Name      ID   狀態State    空閑時間Idle Time     登錄時間Logon Time
administrator            console                               0   運行中               .                           2007-1-12 10:24
lucy                                                                           1   唱片            無                            2007-1-12 10:35
>administrator         rdp-tcp#35                      2   已斷開               .                          2007-1-25 18:09
此時可以看出的可能跟我的不一樣，根據你的具體情況而定。
ID 0 的用戶是本地登陸的
ID 1 和 ID 2是3389登陸的用戶，前者在運行中， 后者已經斷開了，但是斷開了仍然占用系統資源和通道，我們要把它踢掉，如下進行操作即可。
輸入命令：logoff 1
再看看
C:\Documents and Settings\Administrator.AD>query user
用戶名Username      會話名Session Name      ID   狀態State    空閑時間Idle Time     登錄時間Logon Time
administrator          console                                0   運行中               .                          2007-1-12 10:24
>administrator       rdp-tcp#35                       2   已斷開               .                          2007-1-25 18:09
3、如果服務器關閉了telnet功能（這是默認的），還可以通過SqlServer的xp_cmdshell擴展存儲過程，使用格式：master.dbo.xp_cmdshell ''''命令內容''''，其余可參考第二步。此方式要求有訪問xp_cmdshell的權限。
法三（最佳方法－推薦）：限制已斷開鏈接的會話存在時間
一般情況下，我們在維護遠程服務器時，不可能長時間在線，但是系統默認的卻是只要登錄就不再斷開。因此，我們可以修改這一默認設置，給它指定一個自動斷開的時間即可。
可以在Windows 2003 服務器上通過組策略中設置一下來解決問題：單擊"開始→運行"，輸入"gpedit.msc"，回車后打開組策略窗口，然后依次定位到"計算機配置→管理模板→Windows 組件→終端服務→會話"，然后在右側窗口中雙擊"為斷開的會話設置時間限制"，在打開的窗口中將"結束斷開連接的會話"時間設置為5分鐘，或者設置為空閑就斷開。
或
在遠程服務器上打開“運行”窗口，輸入“tscc.msc”連接設置窗口。然后雙擊“連接”項右側的“RDP-Tcp”，切換到“會話”標簽，選中“替代用戶設置”選項，再給“結束已斷開的會話”設置一個合適的時間即可。
法四：增加連接數量，即設置可連接的數量多些
默認情況下允許遠程終端連接的數量是2個用戶，我們可以根據需要適當增加遠程連接同時在線的用戶數。
單擊“開始→運行”，輸入“gpedit.msc”打開組策略編輯器窗口，依次定位到“計算機配置→管理模板→Windows 組件→終端服務”，再雙擊右側的“限制連接數量”，將其TS允許的最大連接數設置大一些即可。
經過上面兩個配置(法三&法四)，基本上就可以保證遠程終端連接時不再受限。但仍有人反映，當前同時只有一個用戶進行連接，卻提示超出最大允許鏈接數，這又是什么原因呢？出現這種情況是因為操作不當所造成的。在上一個帳戶登錄遠程桌面后退出時，沒有采用注銷的方式，而是直接關閉遠程桌面窗口，那么導致該會話并沒有被釋放，而是繼續保留在服務器端，占用了連接數，這樣就會影響下一個用戶的正常登錄了。
法五：限制用戶會話數
對Terminal Services進行限制，使得一個用戶僅僅能夠連接一次
對于Windows Server 2003，請在Terminal Services Configuration（Terminal Services配置）中將“限制每位用戶只有擁有一個會話”（Restrict each user to one session）設置為“是”（Yes）。此外，您可以將“限制終端服務用戶使用單個遠程會話”組策略設置為“啟用”。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/62guangye/archive/2010/02/05/5291415.aspx

介紹：

     getDefinitionByName是flash.utils下面的，屬于工具包類。正如函數名稱是通過Name來獲得該名稱所對應的類對象，意思就是說通過一個類的名稱能夠獲取到該類對象，從而通過該類對象聲明一個該類的實例對象。注意該函數中的參數name=類路徑+類名稱。

實例：

     var btncls:Class = getDefinitionByName("mx.controls.Button") as Class ;

     var myBtn:Object = new btncls() ;

     myBtn.label = "我是通過名字獲得類實例聲明出來的BTN" ;

      this.addChild( myBtn as DisplayObject ) ;

應用：

     現在在flex里面要用到在flash cs3 設計一批元件，當然可以通過導出元件的swc然后添加到工程下面的libs下，當需要在flex里面把這些若干元件當成庫來獲取庫中的單個元素時，我們就可以通過geDefinitionByName函數來實現，具體實現步驟為下：

     第一：在flash cs3中準備好若干個元件，并為元件添加鏈接名稱（最好鏈接名稱和元件名稱一樣）。然后在場景的第一幀里面添加代碼如下：

      function getClassByName(cname:String):Class  //cname即為元件的鏈接名稱。
      {
         var mc:Class =  getDefinitionByName(cname) as Class;
         return mc;
      }

      然后生成swf。

      第二：將swf文件放入工程中，用loader將swf文件導入到程序中。在loader導入成功（觸發Event.Complete事件）后，loader.content即為swf。然后訪問對象的getClassByName()來獲取swf中的元件。存入庫中，以備后用。

      代碼如下：

      var nameArr:Array = ["燭光","菊花"] ;

      var mcArr:Array = new Array() ;

      function init():void

      {

            var loader:Loader = new Loader() ;

            loader.contentLoaderInfo.addEventLinstener( Event.COMPLETE , onComplete  ) ;

            loader.load(new URLRequest("assets/firelib.swf")) ;

       }

       function onComplete(evnet:Event):void

       {

          for(var i:uint=0 ; i<nameArr.length ; i++)

          {

             var cls:Class = Object( event.target.content).getClassByName(nameArr[i]) ;//getClassByName()即為swf場景中定義的函數。

             mcArr.push( { name:nameArr[i] , content:new cls() } ) ;

           }

       }

延伸：

     getQualifiedClassName(value:*)String

          根據一個對象返回該對象的包含完全限定類名稱的字符串。

      getQualifiedSuperClassName(value:*)String

          根據一個對象返回該對象的基類的完全限定類名的字符串。

      在通過上面兩個方法得到一個完全限定類名稱之后，運用 getDefinitionByName()就可以將類名轉換成類應用。

一，Flex,java在一個項目中。

二，Flex,java分別在兩個項目中。

第一種，直接在新建Flex項目中選擇應用服務器，選擇blazeDS即可。

注意要寫上輸出文件夾url.endpoint="messagebroker/amf" 寫上相對路徑即可。

第二種，分別新建Flex ,java 項目，blazeds.war項目中的WebConten/Web-Inf替代java項目下的web-inf。在remoting-config.xml下寫上：

<destination id="hxh">  
       <properties>  
           <source>com.demo.hxh</source>  
       </properties>  
    </destination>  
并布署為tomcat.

Flex項目中修改endpoint="/hxh/messagebroker/amf"，并設置輸出文件夾為java ,WebContent下的，輸出文件夾url為java項目，如為http://localhost:8400/hxh

或者新建項目如一，在新建項目java把編譯目錄設為Flex-webcontent-classes下。

一般問題都錯在設置上，endpoint是一個注意點。

關于endpoint:

public interface Endpointextends ManageableAn endpoint receives messages from clients and decodes them, then sends them on to a MessageBroker for routing to a service. The endpoint also encodes messages and delivers them to clients. Endpoints are specific to a message format and network transport, and are defined by the named URI path on which they are located.

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/bill1315/archive/2010/07/21/5751496.aspx

var x:Number=Capabilities.screenResolutionX;

var y:Number=Capabilities.screenResolutionY;

Alert.show("x="+x+"y="+y);

第二種方法

Alert.show(stage.fullScreenWidth+"=="+stage.fullScreenHeight);

//獲得stage（工作區）的寬、高

Alert.show(stage.stageWidth+"=="+stage.stageHeight);

//讀取xml文件
private function readxml2():void

{

var urlrequest:URLRequest=new URLRequest("file/stu.xml");

var urlloader:URLLoader=new URLLoader(urlrequest);

urlloader.addEventListener(Event.COMPLETE, completehandler);

}

private function completehandler(event:Event):void

{

var xml:XML=new XML(event.target.data);

// var arr:Array=new Array(xml);

this.dg.dataProvider=xml.children();

this.tree.dataProvider=xml;

this.cb.dataProvider=xml.children();

// this.hlist.dataProvider=xml.children();

}

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/xuhuanchao/archive/2009/10/31/4749241.aspx

Jar包沖突問題是在大型Java軟件開發中經常遇到的問題，系統開發人員經常會為解決類似的問題耗費大量的時間進行調試和測試，本文根據各種際情況，結合WebSphere中類加載器，討論了幾種解決jar包沖突問題的辦法，并給出了具體實現的步驟及源代碼。
讀者定位為具有Java和WebSphere開發經驗的開發人員。
讀者可以學習到在WebSphere中類加載器的定義以及解決jar包沖突問題的幾種辦法，并可以直接使用文章中提供的Java代碼，從而節省他們的開發和調試時間，提高效率。

        大型的基于WebSphere的項目開發中，同一個WebSphereApplicationServer（以下簡稱WAS）上會部署多個應用程序，而這多個應用程序必然會共用一些jar包，包括第三方提供的工具和項目內部的公共jar等。把這些共用的jar包提取出來在多個應用程序之間共享，不僅可以統一對這些jar包進行維護，同時也提高了WAS的性能。但是隨著應用的不斷擴大，新的應用程序的不斷增加，新的應用程序會希望使用一些更高版本的共享jar包，而由于系統運行維護的需要，老的應用程序仍然希望用老版本的共享jar包，這樣就必然造成了共享jar包的版本沖突。jar包版本沖突問題是在大型應用項目的開發中經常遇到的問題，本文試圖從WebSphere的類加載器入手，討論幾種在不同情況下解決jar包沖突問題的辦法。
WebSphere中類加載器介紹
Jar包沖突實際上是應用程序運行時不能找到真正所需要的類，而影響類的查找和加載的是JVM以及WebSphere中的類加載器（class loader），為此，我們首先介紹一下WebSphere中的類加載器以及一些相關的概念。
WebSphere中類加載器層次結構
Java應用程序運行時，在class執行和被訪問之前，它必須通過類加載器加載使之有效，類加載器是JVM代碼的一部分，負責在JVM虛擬機中查找和加載所有的Java 類和本地的lib庫。類加載器的不同配置影響到應用程序部署到應用程序服務器上運行時的行為。JVM和WebSphere應用程序服務器提供了多種不同的類加載器配置， 形成一個具有父子關系的分層結構。WebSphere中類加載器的層次結構圖1所示：

圖1：WebSphere中類加載器的層次結構

• JVM Class loader：位于整個層次結構的最上層，它是整個類加載器層次結構的根，因此它沒有父類加載器。這個類加載器負責加載JVM類， JVM 擴展類，以及定義在classpath 環境變量上的所有的Java類。
• WebSphere Extensions Class loader：WebSphere 擴展類加載器, 它將加載WebSphere的一些runtime 類，資源適配器類等。
• WebSphere lib/app Class loader：WebSphere服務器類加載器，它將加載WebSphere安裝目錄下$(WAS_HOME)/lib/app路徑上的類。 在WAS v4版本中，WAS使用這個路徑在所有的應用程序之間共享jar包。從WAS v5開始， 共享庫功能提供了一種更好的方式，因此，這個類加載器主要用于一些原有的系統的兼容。
• WebSphere "server" Class loader：WebSphere應用服務器類加載器。 它定義在這個服務器上的所有的應用程序之間共享的類。WAS v5中有了共享庫的概念之后，可以為應用服務器定義多個與共享庫相關聯的類加載器，他們按照定義的先后順序形成父子關系。
• Application Module Class Loader：應用程序類加載器，位于層次結構的最后一層，用于加載J2EE應用程序。根據應用程序的類加載策略的不同，還可以為Web模塊定義自己的類加載器。

• 每個類加載器負責在自身定義的類路徑上進行查找和加載類。
• 一個子類加載器能夠委托它的父類加載器查找和加載類，一個加載類的請求會從子類加載器發送到父類加載器，但是從來不會從父類加載器發送到子類加載器。
• 一旦一個類被成功加載，JVM 會緩存這個類直至其生命周期結束，并把它和相應的類加載器關聯在一起，這意味著不同的類加載器可以加載相同名字的類。
• 如果一個加載的類依賴于另一個或一些類，那么這些被依賴的類必須存在于這個類的類加載器查找路徑上，或者父類加載器查找路徑上。
• 如果一個類加載器以及它所有的父類加載器都無法找到所需的類，系統就會拋出ClassNotFoundExecption異常或者NoClassDefFoundError的錯誤。

• Parent_First：在加載類的時候，在從類加載器自身的類路徑上查找加載類之前，首先嘗試在父類加載器的類路徑上查找和加載類。
• Parent_Last：在加載類的時候，首先嘗試從自己的類路徑上查找加載類，在找不到的情況下，再嘗試父類加載器類路徑。

• Single：整個應用服務器上的所有應用程序使用同一個類加載器。在這種配置下，每個應用程序不再有自己的類加載器。
• Multiple：應用服務器上的每個應用程序使用自己的類加載器。

• Application：整個應用程序內的所有的實用程序jar包和Web模塊使用同一個類加載器。
• Module：應用程序內的每個Web模塊使用自己的類加載器。應用程序的類加載器仍然存在，負責加載應用程序中Web模塊以外的其它類，包括所有的實用程序jar包。

• 多個應用程序間jar包沖突：多個應用程序間由于使用了共享jar包的不同版本而造成jar包版本沖突。
• 應用程序中多個Web模塊間jar包沖突：同一個應用程序內部，不同的Web模塊間同時使用一個jar包的不同版本而造成jar包版本沖突。
• 應用程序中同一個Web模塊內jar包沖突：同一個應用程序內部，同一個Web模塊內，由于需要同時使用同一個jar包的兩個版本而造成的jar包沖突

• 共享庫方式解決jar包沖突：主要解決應用程序間的jar包沖突問題
• 打包到Web模塊中解決jar包沖突：主要解決應用程序中多個Web模塊間jar包沖突問題
• 命令行運行方式解決jar包沖突：主要解決應用程序中同一個Web模塊內jar包沖突問題

• 步驟一: 進入Admin console，選擇Environment > Shared Library > new。如圖2所示：

圖2：WebSphere Admin Console中進入共享庫頁面

步驟二： 給出共享庫的名字，并指定共享的文件和目錄。多個不同的文件/目錄之間通過"Enter"鍵分隔，且不能有路徑分隔符，如":"和";"等。如圖3所示：

圖3：WebSphere Admin Console中添加共享庫

步驟三：點擊Apply或者OK之后，就添加了一個名字為Xerces V2.0的共享庫。記住添加完成后一定要在admin console保存配置。如圖4所示：

圖4：WebSphere Admin Console中共享庫列表

2．安裝應用程序
進入Admin console，選擇Applications > Install New Application 安裝應用程序。請參照IBMWebSphere的Admin console使用手冊進行安裝新的應用程序，此處不再詳細介紹。
3．將共享庫關聯到應用程序

• 步驟一：進入Admin console，選擇Applications >Enterpriseapplications ，并選擇需要使用共享庫的應用程序。注意：因為要改變應用程序的設置，所以如果應用程序已經運行，需要先停掉應用程序。如圖5所示：
  
  圖5：WebSphere Admin Console中選擇需要配置的應用程序
• 步驟二: 點擊應用程序，進入后，選擇Libraries。如圖6所示：
  
  圖6：WebSphere Admin Console中選擇應用程序庫屬性
• 步驟三: 點擊Add，為應用程序添加共享庫。如圖7所示：
  
  圖7：WebSphere Admin Console中應用程序添加庫
• 步驟四: 從下拉列表中選擇所需要的共享庫，點擊OK。如圖8所示：
  
  圖8：WebSphere Admin Console中應用程序添加庫頁面指定所用的共享庫

這樣，Xerces V2.0共享庫定義的xerces版本就存在于了應用程序類加載器的類加載路徑上。注意，在添加完成后要保存服務器的設置。
4．設置應用程序的類加載器的委托模式為Parent_Last
為了進一步防止共享庫定義的jar包的其它版本已經存在于JVM或者WebSphere的類加載器路徑上，還需要設置應用程序的類加載器的委托方式為Parent_Last。

• 步驟一：進入Admin console，選擇Applications > Enterprise applications > ，選擇需要配置的應用程序。如圖9所示：
  
  圖9：WebSphere Admin Console中選擇需要配置的應用程序
• 步驟二：點擊進入應用程序，設置類加載器的委托模式為Parent_Last。注意：在配置完成后，要保存配置，最后啟動應用程序。如圖10所示：
  
  圖10：WebSphere Admin Console中為應用程序設置類加載器委托模式

通過上面的配置，即使xerces的其它版本已經存在于系統中，應用程序在運行時，其類加載器也會首先查找并加載指定的共享庫中的xerces版本。這樣我們就通過使用共享庫的方式，解決了jar包版本沖突問題。
打包到Web模塊中解決jar包沖突
共享庫的方式，只是在應用程序的層次上，在多個應用程序之間解決了共享jar包造成的版本沖突問題，如果一個應用程序的內部，其中一個Web模塊使用了一個jar包的A版本，而另一個Web模塊使用這個jar包的B版本，在這種情況下造成的jar包沖突，共享庫的方式是無法解決的，我們可以考慮將其中一個在多個應用程序間共享的jar包版本，比如A版本，定義成共享庫，或者放在"WebSphere lib/app Class loader"類加載器路徑上供多個應用程序使用，而將B版本的jar包打包到使用它的Web模塊中的方式來解決沖突。
其次，目前很多在線的系統是WAS v4的遺留系統，其上運行的應用程序已經使用了"WebSphere lib/app Class loader"類加載器，將jar包放在$(WAS_HOME)/lib/app目錄下進行共享。如果由于其中某個應用程序的升級或者新增加某個應用程序，需要使用某個共享jar包的其它版本，在這種情況下，為了減少對系統的影響，也可以考慮將這個共享jar包的新版本打包到升級（或新增）的應用程序中的方式來解決jar包沖突。
由于Web模塊的WebContent/WEB-INFO/lib目錄在應用程序Web模塊的類加載器查找路徑上，因此，我們可以把jar包放在這個目錄下，Web模塊的類加載器將自動查找并加載這個jar包中的類。

• 步驟一：在WSAD IE集成開發環境中，將沖突jar包放在Web模塊的WebContent/WEB-INFO/lib目錄下。如圖11所示：
• 
  
  圖11：WSAD IE中為Web模塊添加庫
• 步驟二：在Admin console中，將應用程序部署到WebSphere server上之后，進入Applications > Enterprise Applications,選擇相應的應用程序，并確認應用程序不在運行狀態(參見前面章節中選擇應用程序的步驟)。點擊進入應用程序，確認應用程序的類加載器的委托模式為Parent_First,應用程序的類加載器策略為Module。如圖12所示：
  
  圖12：WebSphere Admin Console中應用程序屬性配置頁面
• 步驟三：在同一個頁面上，選擇 Web Modules，點擊進入。如圖13所示：
  
  圖13：WebSphere Admin Console中選擇應用程序Web模塊屬性
• 步驟四：點擊相應的包含沖突jar包的Web模塊，設置Web模塊的類加載器的委托模式為Parent_Last。注意：在設置完成后要保存服務器配置，并啟動應用程序。如圖14所示：
  圖14：WebSphere Admin Console中為Web模塊指定類加載器委托模式
• 將沖突jar包打包到Web模塊中，并設置相應Web模塊的類加載器的委托模式為Parent_Last，應用程序在運行過程中加載類的時候，這個Web模塊的類加載器會首先查找 WebContent/WEB-INFO/lib目錄下的jar包進行類的加載；而對于其它的Web模塊，由于其類加載器的委托模式仍然為缺省的Parent_First，它們的類加載器仍然首先從應用程序的共享庫或者WebSphere的共享路徑上加載jar包中的類，從而解決了jar包沖突的問題。
  命令行運行方式解決jar包沖突
  不論是設置共享庫，還是將沖突jar包打包到應用程序中，其解決的問題都是在應用程序的一個Web模塊中只使用了沖突jar包的一個版本的情況。我們在開發中曾經遇到過這樣的情況：應用程序的Web模塊中已經使用了1.4版本的xerces.jar，由于Web功能的擴展，在這個模塊中又引入一個新的第三方工具，而這個第三方工具需要使用2.0版本的xerces.jar才能正常工作，這種情況下的jar包沖突如何解決呢？
  在前面類加載器的部分已經介紹過，每個應用程序的一個Web模塊最多只能有一個類加載器，而Web模塊的類加載器中加載的類的生命周期為整個應用程序的運行期，也就是說，Web模塊加載器不可能同時加載一個類的兩個版本，同時，Web模塊的類加載器的委托模式也是在應用程序運行前設置的，在應用程序運行期內無法改變的，因此，上面描述的在一個Web模塊中同時使用兩個版本的jar包的問題，象前兩種方法那樣配置運行在一個JVM內的類加載器的設置的方法是無法解決的。
  唯一的解決辦法就是在應用程序運行的JVM外，啟動另外一個JVM來運行調用沖突jar包的代碼，因為兩個不同的JVM可以加載各自的類，從而解決jar包沖突問題。
  這種情況下，原來使用jar包的老版本的方式（包括jar包放置路徑，共享庫設置方式，類加載器的委托模式等）不變，將對jar包新版本的調用通過命令行運行方式實現。具體做法是：將對jar包新版本內功能的調用，封裝到一個可以單獨運行的類中，在Web模塊中以命令行方式運行這個類。同時把這個類以及jar包的新版本放在任意一個was可訪問的路徑上（比如/usr/WebSphere），在命令行的classpath參數中包含這個路徑（比如/usr/WebSphere）。
  下面通過舉例說明命令行運行方式的編程過程，在本例中，假設TestEar應用程序的Web模塊TestWar中，已經使用了conflict_v1.jar，由于新添功能需要使用conflict_v2.jar中的exampleCall()功能。
  沖突jar包conflict_v2.jar提供的功能：
  
  代碼1：沖突jar包conflict_v2.jar功能
  

  Package com.ibm.conflict public class ConflictClass{    …….Public static String exampleCall(string param){    String rs;    ……;    Return rs;}……}

  
  不存在沖突問題時的編碼舉例：
  如果沒有jar包沖突問題，則對這個功能的調用是簡單的，只需要將conflict_v2.jar放在應用程序自身或者其父類加載器的查找路徑上，然后在Web模塊中直接調用即可，如下：
  
  代碼2：不存在沖突時的調用方式
  

  Public String methodA(String param){   ……   String rs = ConflictClass.exampleCall(param);   ……   Return rs;}

  
  存在沖突后的命令行運行方式編碼舉例
  針對jar包沖突問題，我們需要在Web模塊中做如下的修改：
  
  • 步驟一：將沖突jar包放在was可訪問的路徑上，比如/usr/WebSphere/conflict_v2.jar。
  • 步驟二：將對包含沖突代碼的調用封裝到一組可單獨運行的類中，它們將調用沖突jar包的功能，并將結果以系統輸出的方式打印到系統標準輸出上。 將這些類封裝到一個單獨的jar文件中，比如workAroundConflict.jar，并將其放在was可訪問的路徑上，比如/usr/WebSphere/workAroundConflict.jar。
    

    Package com.ibm.test;Import com.ibm.ConflictClassublic class WorkAround{Public static void main(String[] args){    String param1=args[0];    String returnStr=ConflictClass.exampleCall ();    System.out.println("<RTStr>"+returnStr+"</RTStr>");    Return;}}

    
    
    代碼3：將對沖突代碼的調用寫入一個單獨的類WorkAround
  • 步驟三：在Web模塊中通過命令行方式調用封裝的類，通過classpath指定所有依賴的jar包和類路徑。運行封裝類，從系統標準輸出中取得運行結果。
    

    Public static String methodA (String param){    ……    String rtStr = "";    String lStr="<RTStr>";    String rStr="<RTStr>";    //put all the dependency jar here    String classPath="/usr/WebSphere/conflict_v2.jar; /usr/WebSphere/workaroundConflict.jar;……";    String className="com.ibm.test.WorkAround";    String cmdLine="java -classpath " +classPath +" " +className + " "+ param;    Try{        Processprocess = Runtime.getRuntime().exec(cmdLine,null);        process.waitFor();        BufferedReader br= new BufferedReader(                  new InputStreamReader(process.getInputStream()));        while ((s = br.readLine())!=null) {            if (null == out)                ut=s;            else                out+=s;}//get result from outif (null != out){    int lIndex = out.lastIndexOf(lStr);    int rIndex = out.lastIndexOf(rStr);    rsStr = out.substring(lIndex+lStr.length, rIndex);}    } catch (Exception e){        e.printStackTrace();}…….return rsStr;}

    
    
    代碼4：在應用程序中通過命令行方式運行WorkAround
  命令行運行方式通過啟動另外一個JVM的方式運行沖突代碼，在一個不同的JVM中加載沖突的類，從而解決了jar包沖突問題。
  但是命令行運行方式畢竟不是一個很好的方式，它存在以下的弊端：
  
  • 命令行運行方式只適用于對沖突jar包的使用只是運行一段代碼，或者只要求返回簡單的字符串結果的情況。對于復雜的交互，命令行方式無法做到。但是如果在別無他法的情況下，可以適當地劃分封裝對沖突代碼調用的jar包的包含范圍，盡量將命令行運行的代碼接口簡單化。
  • 命令行運行方式因為啟動了另外一個JVM來運行，降低了WebSphere的性能。
  因此，命令行方式只適用于一些極為特殊的情況下解決jar包沖突問題。
  結論
  本文對基于WebSphere的大型項目開發中遇到的jar包沖突問題，結合WebSphere中類加載器的概念，給出了三種解決辦法以及相應的操作步驟和實現代碼，并分析了各種方式所適用的具體情況。
  項目開發過程中的jar包沖突，主要存在以下三種情況：
  
  • 多個應用程序間的jar包沖突
  • 應用程序內多個Web模塊間的jar包沖突
  • 應用程序內同一個Web模塊內部jar包沖突
  通過對類加載器的分析我們知道，解決jar包沖突問題的根本在于合理配置類加載器。在深入理解WebSphere中類加載器的層次結構的基礎上，我們給出了"共享庫解決jar包沖突"以及"打包到Web模塊中解決jar包沖突"的辦法，通過合理地配置WebSphere中類加載器及其委托模式，可以解決大多數的jar包沖突問題。但是由于這個層次結構中類加載器只配置到Web模塊，因此，對于Web模塊內部的jar包沖突問題，類加載器的配置是無法解決的，為此我們給出了"命令行運行方式解決jar包沖突"的辦法。
  表2中列出了在不同的WAS版本下，三種解決jar包沖突問題的辦法所適用的jar包沖突情況。
  
  表2：Jar包沖突解決辦法適用的jar包沖突情況總結