現有項目組用SUN JDK1.5中自帶的示例：jnlp-servlet作為WEBSTART版本管理的SERVLET。它可以很好的實現JNLP相關資源（JAR，圖片等）的基于版本的管理和增量更新。并有幾個類似 $ $codebase， $ $name的可替換關鍵字。（原來寫了一個簡單的servlet，可以實現軟編碼，但沒法提供靈活的版本控制）

但現有項目的需求更高一些，即，JNLP中需要傳更多的參數，比如，服務端IP，端口，上下文，用戶登錄的SESSIONID等，由于jnlp-servlet有源代碼，我們很快修改了JnlpFileHandler和specializeJnlpTemplate方法，并加入了這幾個自定義關鍵字（ $ $host, $ $port, $ $newcontext, $ $sessionid）。JNLP如下所示：

<?xml version="1.0" encoding="utf-8"?>

<jnlp spec="1.0 " codebase=" $ $codebase" href=” $ $name”>

<information>

<title>My System</title>

<vendor>CFR</vendor>

<icon href="indexbannerleft.jpg" kind="splash" />

<homepage href="index.html"/>

<description>My System</description>

<description kind="short">CFR Inc..</description>

</information>

<security><all-permissions/></security>

<resources>

<j2se version="1.4" initial-heap-size="32m"/>

<jar href="myapp.jar" version="1.1"/>

<nativelib href="swt-lib.jar" version="1.1"/>

</resources>

<resources os="Windows"><jar href="swt.jar" version="1.1"/></resources>

<resources os="Windows"><jar href="jface.jar" version="1.0"/></resources>

<resources os="Windows"><jar href="osgi.jar" version="1.0"/></resources>

<resources os="Windows"><jar href="runtime.jar" version="1.0"/></resources>

<application-desc main-class="com.cfr.app.main">

<argument> $ $session</argument>

<argument> $ $host</argument>

<argument> $ $port</argument>

<argument> $ $newcontext</argument>

<argument>0</argument>

<argument>aa</argument>

</application-desc>

</jnlp>

其中，SESSIONID是用其內部的request得到。

一切好象即簡單和明了，工作正常，但很快就發現了嚴重的問題。

首先說說該應用的使用模式如下：

1、 用戶從網頁登錄系統，然后在里面點擊：http://host:port/myapp/swt/index.jnlp鏈接。

2、 啟動應用（因為應用是跟當前登錄SESSION直接相關的）

按照設計本意，此時，用戶的應用應通過JNLP中的參數得到了該用戶登錄后的SESSIONID才對，但事實并非如此。這種情況只出現在WEBSTART第一次下載的時候，以后當用戶重新打開瀏覽器登錄后（此時當然是一個新的SESSION），在頁面中啟動WEBSTART后，發現，該SESSIONID還是以前的，并沒有想象中的將新SESSIONID傳了進來。

后來還是看看JnlpFileHandler中的源代碼，發現主要在getJnlpFile（客戶端是JRE1.5以下時調用）和getJnlpFileEx(客戶端是JDK1.5以上時用)進行了相關實現。原來，它每生成一個JNLP，就將其緩存在HASHMAP中，下一次請求，如果請求的URL相關并且文件的timestamp（就是Web服務器中的jnlp文件的修改時間，可想而知，除了升級，這個文件一般不會變）一樣，就從緩存中取，這樣一來，我們也可以推測，按照上面的設計，如果有一個用戶下載了應用，其它用戶從其它機器下載到的JNLP還是第一個用戶的JNLP，這是一個更加嚴重的問題。

由于URL是一樣的，現在考慮更改時間戳，即在getJnlpFile中顯式的將timesstamp改為當前的時間：

long lastModified = new java.util.Date().getTime();

這樣，任何一次請求都不會從緩存中獲得，而是重新生成一個，好象這能很好的解決這個問題了吧？

但事實遠沒有想象的那么簡單。這跟WEBSTART與服務端的交互過程有關系。

WEBSTART要通過多次從服務端交互才會真正下載JNLP文件，這主要是驗證一些時間等相關的屬性（具體我沒有看代碼）。大至是三次才會真正的把JNLP下載下來（其實服務端會生成三次，真正下載的是第三個），由于我們的SESSIONID是從SERVLET內部的REQUEST中直接得到，這樣一來，實際上只有第一個請求的SESSIONID是正確的（因為它是直接從瀏覽器中進入的），其它兩個都是WEBSTART用URLConnection建立的連接，SESSIONID都是新生成的，而下載的恰恰又是第三個，這樣一來，又黃了?。?！

接下來的想法是自己設法傳SESSIONID，而不是從當前REQUEST中取。所以，就剛才啟動WEBSTART的鏈接改為如下形式：

<a href="/myapp/swt/index.jnlp?sessionid=<%=request.getSession().getId()%>">啟動客戶端程序</a>

這樣，生成的URL會是：

http://localhost:8899/myapp/swt/index.jnlp?sessionid=F8864B2CDF60AE371CD6DFC189E80C78

按照前面的JNLP文件，下載下來的JNLP第一行是：

<jnlp spec="1.0 " codebase="http://127.0.0.1:8899/myapp/swt/" href=” http://localhost:8899/myapp/swt/index.jnlp?sessionid=F8864B2CDF60AE371CD6DFC189E80C78”>

既然有了SESSIONID（這意味著每個請求的URL都不會一樣?。覀兙陀貌恢鴮r間戳改為當前時間了，還按原來的做就行了。

到此為止，好像問題解決的很徹底哦！但不要高興的太早！?。。?！

我們同樣做實驗：

1、 將WEBSTART應用清空

2、 登錄系統，下載安裝應用并運行，一切OK！

3、 退出該系統

4、 打開新的瀏覽器并登錄

5、 點相應的鏈接啟動WEBSTART應用

6、 怪了：SESSIONID怎么還是前面的一個呢？

 查看jnlp-servlet日志，剛才說了，要經過多次握手才會實際的下載JNLP，從流程中發現，客戶端發的請求，第一個是對的即是http://localhost:8899/myapp/swt/index.jnlp?sessionid=F8864B2CDF60AE371CD6DFC189E80C78

 SESSION是最新的，但第二個請求，SESSION怎么就是以前的呢？

原來，WEBSTART在經過第一次握手之后，發現本地有該應用，就用該應用JNLP中的href字段發送下面的請求，導致了剛才的問題。

后面的解決辦法說起來就沒什么了，直接去掉href字段就行了，如下片段：

<?xml version="1.0" encoding="utf-8"?>

<jnlp spec="1.0 " codebase=" $ $codebase">

這樣，每次都用新的URL去請求了??！

說來說去，只是過程，其它代碼中改得并不多，主要是增加了SESSION參數。

在以后動態更改應用的MAIN類時，思路也差不多。

其它人需地做的改動：

更改JNLP，去掉href項

換成新的jnlp_servlet

清除當前已安裝的應用。

LDAP介紹 4
1.1. LDAP是什么 4
1.2. LDAP是電話簿 4
1.3. LDAP是不是數據庫 4

2. LDAP的特點 5
2.1. LDAP的優勢 5
2.1.1 跨平臺 5
2.1.2 費用及維護 5
2.1.3 復制技術 5
2.1.4 允許使用ACI 5
2.2. LDAP存儲什么數據 6
2.3. 什么時候該用LDAP存儲數據 6
3. LDAP的基本模型 7
3.1 信息模型：描述LDAP的信息表示方式 7
3.2 命名模型：描述LDAP中的數據如何組織 7
3.3 功能模型：描述LDAP中的數據操作訪問 7
3.4 安全模型：描述LDAP中的安全機制 8
3.4.1 身份認證 8
3.4.2 通訊安全 8
3.4.3 訪問控制 8

4. LDAP數據結構 9
4.1 樹狀組織 9
4.2 條目和條目認證 9
4.3 數據樣式（schema） 9
4.4 對象類型(objectClass) 9
4.5 過濾器和語法 10
4.6 樹移植 10
4.7 LDIF交換文件 10
4.8 JAVA或CORBA對象串行化存儲 10

1.1. LDAP是什么
LDAP是輕量目錄訪問協議，英文全稱是Lightweight Directory Access Protocol，一般都簡稱為LDAP。它是基于X.500標準的，但是簡單多了并且可以根據需要定制。與X.500不同，LDAP支持TCP/IP，這對訪問Internet是必須的。LDAP的核心規范在RFC中都有定義，所有與LDAP相關的RFC都可以在LDAPman RFC網頁中找到。
簡單說來，LDAP是一個得到關于人或者資源的集中、靜態數據的快速方式。
LDAP是一個用來發布目錄信息到許多不同資源的協議。通常它都作為一個集中的地址本使用，不過根據組織者的需要，它可以做得更加強大。
1.2. LDAP是電話簿
LDAP其實是一電話簿，類似于我們所使用諸如NIS(Network Information Service)、DNS (Domain Name Service)等網絡目錄，也類似于你在花園中所看到的樹木。
1.3. LDAP是不是數據庫
不少LDAP開發人員喜歡把LDAP與關系數據庫相比，認為是另一種的存貯方式，然后在讀性能上進行比較。實際上，這種對比的基礎是錯誤的。LDAP和關系數據庫是兩種不同層次的概念，后者是存貯方式（同一層次如網格數據庫，對象數據庫），前者是存貯模式和訪問協議。LDAP是一個比關系數據庫抽象層次更高的存貯概念，與關系數據庫的查詢語言SQL屬同一級別。LDAP最基本的形式是一個連接數據庫的標準方式。該數據庫為讀查詢作了優化。因此它可以很快地得到查詢結果，不過在其它方面，例如更新，就慢得多。
從另一個意義上 LDAP是實現了指定的數據結構的存貯，它是一種特殊的數據庫。但是LDAP和一般的數據庫不同，明白這一點是很重要的。 LDAP對查詢進行了優化，與寫性能相比LDAP的讀性能要優秀很多。
就象Sybase、Oracle、Informix或Microsoft的數據庫管理系統（DBMS）是用于處理查詢和更新關系型數據庫那樣，LDAP服務器也是用來處理查詢和更新LDAP目錄的。換句話來說LDAP目錄也是一種類型的數據庫，但不是關系型數據庫。要特別注意的是，LDAP通常作為一個hierarchal數據庫使用，而不是一個關系數據庫。因此，它的結構用樹來表示比用表格好。正因為這樣，就不能用SQL語句了。
2. LDAP的特點
2.1. LDAP的優勢
2.1.1 跨平臺
LDAP最大的優勢是：可以在任何計算機平臺上，用很容易獲得的而且數目不斷增加的LDAP的客戶端程序訪問LDAP目錄。而且也很容易定制應用程序為它加上LDAP的支持。
LDAP協議是跨平臺的和標準的協議，因此應用程序就不用為LDAP目錄放在什么樣的服務器上操心了。實際上，LDAP得到了業界的廣泛認可，因為它是Internet的標準。產商都很愿意在產品中加入對LDAP的支持，因為他們根本不用考慮另一端（客戶端或服務端）是怎么樣的。LDAP服務器可以是任何一個開發源代碼或商用的LDAP目錄服務器（或者還可能是具有LDAP界面的關系型數據庫），因為可以用同樣的協議、客戶端連接軟件包和查詢命令與LDAP服務器進行交互。與LDAP不同的是，如果軟件產商想在軟件產品中集成對DBMS的支持，那么通常都要對每一個數據庫服務器單獨定制。
2.1.2 費用及維護
不象很多商用的關系型數據庫，你不必為LDAP的每一個客戶端連接或許可協議付費。
大多數的LDAP服務器安裝起來很簡單，也容易維護和優化。
2.1.3 復制技術
LDAP服務器可以用"推"或"拉"的方法復制部分或全部數據，例如：可以把數據"推"到遠程的辦公室，以增加數據的安全性。復制技術是內置在LDAP服務器中的而且很容易配置。如果要在DBMS中使用相同的復制功能，數據庫產商就會要你支付額外的費用，而且也很難管理。
2.1.4 允許使用ACI
LDAP允許你根據需要使用ACI（一般都稱為ACL或者訪問控制列表）控制對數據讀和寫的權限。例如，設備管理員可以有權改變員工的工作地點和辦公室號碼，但是不允許改變記錄中其它的域。ACI可以根據誰訪問數據、訪問什么數據、數據存在什么地方以及其它對數據進行訪問控制。因為這些都是由LDAP目錄服務器完成的，所以不用擔心在客戶端的應用程序上是否要進行安全檢查。
2.2. LDAP存儲什么數據
LDAP對于這樣存儲這樣的信息最為有用：也就是數據需要從不同的地點讀取，但是不需要經常更新。例如，這些信息存儲在LDAP目錄中是十分有效的：
l 公司員工的電話號碼簿和組織結構圖
l 客戶的聯系信息
l 計算機管理需要的信息，包括NIS映射、email假名，等等
l 軟件包的配置信息
l 公用證書和安全密匙
2.3. 什么時候該用LDAP存儲數據
大多數的LDAP服務器都為讀密集型的操作進行專門的優化。因此，當從LDAP服務器中讀取數據的時候會比從專門為OLTP優化的關系型數據庫中讀取數據快一個數量級。也是因為專門為讀的性能進行優化，大多數的LDAP目錄服務器并不適合存儲需要需要經常改變的數據。例如，用LDAP服務器來存儲電話號碼是一個很好的選擇，但是它不能作為電子商務站點的數據庫服務器。
如果下面每一個問題的答案都是"是"，那么把數據存在LDAP中就是一個好主意。
l 需要在任何平臺上都能讀取數據嗎？
l 每一個單獨的記錄項是不是每一天都只有很少的改變？
l 可以把數據存在平面數據庫（flat database）而不是關系型數據庫中嗎？換句話來說，也就是不管什么范式不范式的，把所有東西都存在一個記錄中（差不多只要滿足第一范式）。
最后一個問題可能會唬住一些人，其實用平面數據庫去存儲一些關系型的數據也是很一般的。例如，一條公司員工的記錄就可以包含經理的登錄名。用LDAP來存儲這類信息是很方便的。一個簡單的判斷方法：如果可以把保數據存在一張張的卡片里，就可以很容易地把它存在LDAP目錄里。
3. LDAP的基本模型
3.1 信息模型：描述LDAP的信息表示方式
在LDAP中信息以樹狀方式組織，在樹狀信息中的基本數據單元是條目，而每個條目由屬性構成，屬性中存儲有屬性值；LDAP中的信息模式，類似于面向對象的概念，在LDAP中每個條目必須屬于某個或多個對象類（Object Class），每個Object Class由多個屬性類型組成，每個屬性類型有所對應的語法和匹配規則；對象類和屬性類型的定義均可以使用繼承的概念。每個條目創建時，必須定義所屬的對象類，必須提供對象類中的必選屬性類型的屬性值，在LDAP中一個屬性類型可以對應多個值。
在LDAP中把對象類、屬性類型、語法和匹配規則統稱為Schema，在LDAP中有許多系統對象類、屬性類型、語法和匹配規則，這些系統Schema在LDAP標準中進行了規定，同時不同的應用領域也定義了自己的Schema，同時用戶在應用時，也可以根據需要自定義Schema。這有些類似于XML，除了XML標準中的XML定義外，每個行業都有自己標準的DTD或DOM定義，用戶也可以自擴展；也如同XML，在LDAP中也鼓勵用戶盡量使用標準的Schema，以增強信息的互聯互通。
在Schema中最難理解的是匹配規則，這是LDAP中為了加快查詢的速度，針對不同的數據類型，可以提供不同的匹配方法，如針對字符串類型的相等、模糊、大于小于均提供自己的匹配規則。
3.2 命名模型：描述LDAP中的數據如何組織
LDAP中的命名模型，也即LDAP中的條目定位方式。在LDAP中每個條目均有自己的DN和RDN。DN是該條目在整個樹中的唯一名稱標識，RDN是條目在父節點下的唯一名稱標識，如同文件系統中，帶路徑的文件名就是DN，文件名就是RDN。
3.3 功能模型：描述LDAP中的數據操作訪問
在LDAP中共有四類10種操作：查詢類操作，如搜索、比較；更新類操作，如添加條目、刪除條目、修改條目、修改條目名；認證類操作，如綁定、解綁定；其它操作，如放棄和擴展操作。除了擴展操作，另外9種是LDAP的標準操作；擴展操作是LDAP中為了增加新的功能，提供的一種標準的擴展框架，當前已經成為LDAP標準的擴展操作，有修改密碼和StartTLS擴展，在新的RFC標準和草案中正在增加一些新的擴展操作，不同的LDAP廠商也均定義了自己的擴展操作。
3.4 安全模型：描述LDAP中的安全機制
LDAP中的安全模型主要通過身份認證、安全通道和訪問控制來實現。
3.4.1 身份認證
在LDAP中提供三種認證機制，即匿名、基本認證和SASL（Simple Authentication and Secure Layer）認證。匿名認證即不對用戶進行認證，該方法僅對完全公開的方式適用；基本認證均是通過用戶名和密碼進行身份識別，又分為簡單密碼和摘要密碼認證；SASL認證即LDAP提供的在SSL和TLS安全通道基礎上進行的身份認證，包括數字證書的認證。
3.4.2 通訊安全
在LDAP中提供了基于SSL/TLS的通訊安全保障。SSL/TLS是基于PKI信息安全技術，是目前Internet上廣泛采用的安全服務。LDAP通過StartTLS方式啟動TLS服務，可以提供通訊中的數據保密性、完整性保護；通過強制客戶端證書認證的TLS服務，同時可以實現對客戶端身份和服務器端身份的雙向驗證。
3.4.3 訪問控制
雖然LDAP目前并無訪問控制的標準，但從一些草案中或是事實上LDAP產品的訪問控制情況，我們不難看出：LDAP訪問控制異常的靈活和豐富，在LDAP中是基于訪問控制策略語句來實現訪問控制的，這不同于現有的關系型數據庫系統和應用系統，它是通過基于訪問控制列表來實現的，無論是基于組模式或角色模式，都擺脫不了這種限制。
在使用關系型數據庫系統開發應用時，往往是通過幾個固定的數據庫用戶名訪問數據庫。對于應用系統本身的訪問控制，通常是需要建立專門的用戶表，在應用系統內開發針對不同用戶的訪問控制授權代碼，這樣一旦訪問控制策略變更時，往往需要代碼進行變更?？傊痪湓?，關系型數據庫的應用中用戶數據管理和數據庫訪問標識是分離的，復雜的數據訪問控制需要通過應用來實現。
而對于LDAP，用戶數據管理和訪問標識是一體的，應用不需要關心訪問控制的實現。這是由于在LDAP中的訪問控制語句是基于策略語句來實現的，無論是訪問控制的數據對象，還是訪問控制的主體對象，均是與這些對象在樹中的位置和對象本身的數據特征相關。
在LDAP中，可以把整個目錄、目錄的子樹、制定條目、特定條目屬性集或符合某過濾條件的條目作為控制對象進行授權；可以把特定用戶、屬于特定組或所有目錄用戶作為授權主體進行授權；最后，還可以定義對特定位置（例如IP地址或DNS名稱）的訪問權。

4. LDAP數據結構
LDAP是實現了指定的數據結構的存貯，它包括以下可以用關系數據庫實現的結構要求：樹狀組織、條目認證、類型定義、許可樹形記錄拷貝。
4.1 樹狀組織
無論是X500還是LDAP都是采用樹狀方式進行記錄。每一個樹目錄都有一個樹根的入口條目，子記錄全部是這一根條目的子孫。這是目錄與關系數據類型最大的區別（關系數據庫的應用結構也可實現樹狀記錄）。因此，把目錄看作是更高級的樹狀數據庫也未嘗不可，只不過除此外，它不能實現關系存貯的重要功能。
4.2 條目和條目認證
LDAP是以條目作為認證的根據。ROOT的權限認證與目錄本身無關，但除此外所有條目的認證權限由條目本身的密碼進行認證。LDAP可以配置成各種各樣不同的父子條目權限繼承方式。
每一個條目相當于一個單一的平面文本記錄，由條目自身或指定的條目認證進行訪問控制。因此，LDAP定義的存貯結構等同于一批樹狀組織的平面數據庫，并提供相應的訪問控制。
條目中的記錄以名-值對的形式存在，每一個名值對必須由數據樣式schema預定義。因此，LDAP可以看作是以規定的值類型以名值對形式存貯在一系列以樹狀組織的平面數據庫的記錄的集合。
4.3 數據樣式（schema）
數據樣式schema是針對不同的應用，由用戶指定（設計）類和屬性類型預定義，條目中的類(objectclass)和屬性必須在在LDAP服務器啟動時載入內存的schema已有定義。因此，AD活動目錄中的條目記錄就必須符合Active Directory的schema中。如果已提供的schema中的定義不夠用，用戶可以自行定義新的schema.
在http://ldap.akbkhome.com/index.php中可以看到常用的schema。
4.4 對象類型(objectClass)
因為LDAP目錄可以定制成存儲任何文本或二進制數據，到底存什么要由你自己決定。LDAP目錄用對象類型（objectclass）的概念來定義運行哪一類的對象使用什么屬性。在幾乎所有的LDAP服務器中，你都要根據自己的需要擴展基本的LDAP目錄的功能，創建新的對象類型或者擴展現存的對象類型。
條目中的記錄通過objectclass實現分類，objectClass是一個繼承性的類定義，每一個類定義指定必須具備的屬性。如某一條目指定必須符合某個類型，則它必須具備超類所指定的屬性。
通過objectclass分類，分散的條目中的記錄就實際上建立了一個索引結構，為高速的讀查詢打下了基礎。Objectclass也是過濾器的主要查詢對象。
4.5 過濾器和語法
LDAP是一個查詢為主的記錄結構，無論是何種查詢方式，最終都由過濾器缺點查詢的條件。過濾器相當于SQL中的WHERE子句。任何LDAP的類過濾和字符串都必須放在括號內，如（objectclass=*）,指列出所有類型的記錄（不過分類）。
可以使用=，>=，<=，~=（約等于）進行比較，如(number<=100)。合并條件是最怪的，必須把操作符放在兩個操作對象的前面而不是中間，單一操作對象用括號括起來。如
l A與B，不是A&B，而是（&(A)(B)）。
l 或使用"|"表示；
l 非使用"！"表示。
l 對于"與"，或"或"在操作符后可以跟多個條件表達式，但非后則只參是單個表達式。
詳見RFC1558。
4.6 樹移植
LDAP最重要的特性和要求并不是讀性能，而是擴展性。這一特性是通過樹移植和樹復制實現的。按LDAP的RFC要求，LDAP目錄應該可以任意地在不同的目錄間連接、合并并實現自動復制，及自動性同步。這意味著用戶可以在任一LDAP中訪問條目，而不用管其中某一部分是否復制自全世界另一目錄中的記錄，同時另一目錄中的記錄同樣在正常運作。
這一特性如果在關系數據庫中實現，意味著要使用程序化的非規范化預復制。類似于匯總帳目的設計。
4.7 LDIF交換文件
LDIF是LDAP約定的記錄交換格式，以平面文本的形式存在，是大部分LDAP內容交換的基礎，如拷貝、添加、修改等操作，都是基于LDIF文件進行操作。
4.8 JAVA或CORBA對象串行化存儲
網絡高效率的訪問加上JAVA的跨平臺能力，當把JAVA或CORBA對象串行化后存儲到LDAP目錄上時，可以產生非同一般的集成效果--實際上，這正是EJB和.NET的網絡定位基礎技術。
使用JAVA或CORBA對象存儲時，必須首先讓LDAP服務支持該對象定義，也就是說包含qmail.schema或corba.schema。
JAVA必須存儲在objectclass=javacontainer的條目中，而且必須帶有cn屬性，這意味著除非該JAVA類專門實現了DirContext接口，對于大多數JAVA類來說，只能采用DirContext代替Context實現bind的添加操作。取出JAVA類相對要簡單得多，只需使用context.lookup()獲得該對象的句柄，然后強制造型成所需要的對象就可以了,如：
Person p=(Person)contex.lookup("cn=elvis,dc=daifu,dc=com");
這個句法在EJB的程序中，是經常用到的。
使用CORBA的跨語言性質，使用CORBA存儲對象比JAVA更加誘人，這意味著所存儲的對象可以被任何語言編寫的客戶端訪問。其實，微軟的.net說到底也非常簡單，無非是把COM對象存儲到微軟自家的目錄ActiveDirectory里面，從而可以在網絡范圍內使用任何微軟平臺的語言進行對象訪問而已。眾所周知，COM就是與CORBA相對的微軟規范。
使用對象串行化技術，可以把常用對象如某個打印機，某個客戶直接存儲到LDAP中，然后快速獲取該對象的引用，這樣，就比把對象信息存儲到關系數據庫中，分別取出屬性，然后再初始化對象操作的做法，效率要高得多了。這是LDAP目前比普通關系數據庫存儲要優秀的地方，而對象數據庫還不成熟。

方法一：
      1.關閉Eclipse，將插件的安裝壓縮文件解壓縮到某個目錄。
      2.打開Eclipse,點擊主菜單的“幫助”→ “軟件更新” →“管理配置”子菜單，打開產品配置對話框。選中Eclipse SDK單擊右鍵選擇“添加” →“擴展位置”了菜單。在打開的瀏覽文件對話框中，選擇插件的安裝文件目錄。

方法二：

1．將插件的安裝壓縮文件解壓縮到某個目錄。

2．在Eclipse的安裝目錄下建立一名為“links”的文件夾,然后在“links”文件夾下建立一件擴展名為“.links”的文件。文件的內容是：path=插件的安裝壓縮文件的位置。

注意：路徑中的“\”換成“\\”,否則插件將不能成功安裝。

備注：不同版本的插件需要安裝在特定版本的Eclipse下。