IBM WebSphere 常見問題解答
問:在J2EE標準中的EAR，WAR，以及JAR文件中的內(nèi)容是什么？
答: 在J2EE標準定義了所有的EJB classes 都應(yīng)該打包成一個JAR 文件。 所有的web 組件(JSPs, static pages, Servlets, gifs)都應(yīng)該打包在一個WAR 文件里。所有應(yīng)用程序客戶端的classes都應(yīng)該打包成一個JAR文件。EAR文件將會包括所有屬于相對應(yīng)的企業(yè)應(yīng)用程序中的所有JARs文件和WARs 文件。需要強調(diào)的是每個JAR, WAR, 和 EAR文件都將 包括一個Deployment Descriptor文件. Deployment Descriptor 是一個 XML 文件。
問: WebSphere AEs 和AEd 版本有什么不同的地方?
答: AEs 是 WebSphere, Advanced Edition - Single Server 版而 AEd 是 WebSphere, Advanced Edition - Developer 版本。 AEs 和 AEd 的代碼是一樣 的。不同的地方是 AEs 的 license 是可以用于生產(chǎn)環(huán)境中，而AEd 的license不能用于產(chǎn)品環(huán)境 只能用于開發(fā)過程中使用。
問: 在WebSphere中internal/embedded HTTP server的作用是什么?
答: Internal HTTP Server 主要是出于兩個方面的目的來考慮:
內(nèi)置的HTTP server 在生產(chǎn)環(huán)境中不應(yīng)該由終端客戶來直接訪問，因為它相比外置的 HTTP servers 來說少了很多的關(guān)于webserver功能，比如說 caching功能。
問: 在AEs中的 Admin Services 是不是運行在一個單獨的JAVA虛擬機（JVM）中?
答: 不是，AEs的 Admin Services 不是運行在一個單獨的JVM上. AEs 是WebSphere Advanced-Single Server 版本。 AEs 上的 administrative server 和 Application Server 是運行在同一個 Java Virtual Machine上面。
問: 我們所遵循的是什么版本的 HTTP 協(xié)議？
答: 我們通訊所遵循的是HTTP 1.1 的協(xié)議標準。
問: 在UNIX系統(tǒng)上的Silent Install 是不是不需要任何工具比如說 Motif 或 GUI 工具包？
答: 是的。
問: EJBDeploy和SEAppInstall是不是WebSphere 4.0的新工具？
答: EJBDeploy 是一直存在的工具。它在WebSphere4.0 中新的特性是已經(jīng) 轉(zhuǎn)變?yōu)橐粋€命令行的工具，可以使得我們可以在命令行方式下執(zhí)行這個EJB的部署工具，而以前我們 只能在Visual Age for Java 或者 Admin GUI中才能執(zhí)行這個部署工具。SEAppInstall 是在 WebSphere 4.0中出現(xiàn)的一個新工具。它是一個命令行的企業(yè)應(yīng)用程序的安裝工具，只在AEs和AEd版本 中使用。
問: 關(guān)于EJB存儲的 "where" 語句是在什么位置？
答: "Where" 語句是在Application Assembly Tool (AAT)工具中作為EJB 的一個擴展方法來被配置。它們存儲在EJB的擴展文件中，由AAT來配置生成。
問: 關(guān)于stateful session beans的工作負載均衡管理機制是怎么樣的？
答: 在websphere 4.0中stateful session beans 和在Websphere3.5的作用是 一樣的。Stateful session beans 能夠被modeled 和cloned。然而，你不能實現(xiàn)對這些beans的工作量管理。 這是由于stateful session bean 是與一個特定的客戶端密切相關(guān)的。在大多數(shù)情況下，實現(xiàn)對這些EJBs的 工作量管理會使系統(tǒng)運行效率降低，而不是我們所期望的提高系統(tǒng)性能，雖然你可能會提高跨進程訪問的數(shù)目， 但是實際上可能系統(tǒng)需要的更多的跨物理機器調(diào)用的管理。
問: 如何在另外一個應(yīng)用程序服務(wù)器上指定一個遠程的 EJB ？
答: 如果在另外一個應(yīng)用服務(wù)器上的EJB與當前應(yīng)用程序服務(wù)器是在同一個websphere 管理域內(nèi),那么我們不需要采取什么特定的方法。因為在WebSphere 分布式的命名空間內(nèi)，無論EJB位于這個 管理域的任何位置，關(guān)于這個EJB的JNDI查找都會返回它正確的home接口給管理服務(wù)器。
如果EJB是位于另一個WebSphere管理域內(nèi)，那么需要做如下的操作：
在實現(xiàn)EJB的JNDI查找代碼中，將 Context.PROVIDER_URL 設(shè)置成為如下：
Hashtable env = new Hashtable(); env.put(Context.PROVIDER_URL, "iiop://EJBHost"); Context context = new InitialContext(env);
其中 EJBHost 代表EJB駐留的主機的地址。 關(guān)于 Context.PROVIDER_URL 設(shè)置的缺省值是localhost。當然你也可以通過設(shè)置 Context.INITIAL_CONTEXT_FACTORY 的值來選擇其它的查找服務(wù)。
問: 能否提供一些關(guān)于連接池，例如stale connections等的一些信息？
答: Stale connections 表示那些由于某種原因而不能再被使用的連接。這種情況經(jīng)?？赡馨l(fā)生，比如數(shù)據(jù)庫服務(wù)器突然當機或者是網(wǎng)絡(luò)遇到問題不通的情況，都會出現(xiàn)這種連接失效的情況。在這種情況下，連接不能再被應(yīng)用程序所使用，連接池需要涮新或者是重建。對于這種情況在websphere 下就已經(jīng)增加了對它們的支持，在WebSphere4。0中有了進一步的提高。更多指定的數(shù)據(jù)庫廠商的錯誤代碼被增加進來表示為StaleConnectionException的異常代碼。另外，當websphere拋出StaleConnectionException時，整個連接池將被破壞以進一步重建。
問: 關(guān)于JSPs的預(yù)編譯是如何處理實現(xiàn)的？
答: 作為IBM關(guān)于JSP支持的一個重要擴展，IBM WebSphere Application Server 提供一個能夠?qū)崿F(xiàn)批處理的JSP編譯器。使用這種功能能夠成批的編譯處理你的JSP文件，使得客戶端第一次 處理webserver上的JSP頁面時，能夠得到更快的響應(yīng)，以提高你的應(yīng)用的運行性能。
一次性同時編譯關(guān)于一個企業(yè)應(yīng)用程序的所有JSP頁面是一個最好的方法。批處理編譯可以節(jié)約系統(tǒng)資源，同時通過指定服務(wù)器是否檢測相關(guān)的類文件或者重新編譯JSP文件可以提供關(guān)于應(yīng)用程序服務(wù)器的安全性設(shè)置。除非你對應(yīng)用程序服務(wù)器進行相關(guān)的配置，否則應(yīng)用程序服務(wù)器將監(jiān)測已經(jīng)編譯過的JSP文件的變化，當服務(wù)器檢測到JSP頁面發(fā)生變化時，它會自動的重新編譯這些改變的JSP文件，同時將它們重新裝載到服務(wù)器中。
使用 JSPBatchCompiler 工具。目前它在WebSphere4.0 AEs可以正常工作。為了使得 這個工具能夠在beta版的websphere4.0 AE版正常使用?？梢詫⑦@個AE下的批處理文件做一個備份，將文件中的 org.apache.jasper.compiler.ibmtools.BatchC 修改為 org.apache.jasper.compiler.ibmtools.JspBatchCompiler.
這個工具的使用方法為: JspBatchCompiler -enterpriseApp -webModule [-filename] [-keepgenerated]
注意在命令參數(shù)中的企業(yè)應(yīng)用程序指的是已經(jīng)安裝在服務(wù)器上的應(yīng)用程序的名字。而 web module 的名字表示的是屬于此企業(yè)應(yīng)用程序的web module。在WebSphere4.0的 InfoCenter中有關(guān)于這個命令工具的詳細描述。
問：是否能夠指定關(guān)于EJB的CLASSPATH?
答: 能夠, 每一個EJB module中的"classpath" 都能夠在Application Assembly Tool (AAT) 中被配置。
問: 能否指定應(yīng)用程序級的CLASSPATH?
答: 不能。因為應(yīng)用程序級的classpath 是由其包含的每個 module (EJB, Web, Client) 在module 級上 被指定的
問：在 AEs中,bindings信息文件存儲在什么位置？在EAR文件被安裝在應(yīng)用程序服務(wù)器上后，綁定信息是否是儲存在 server-cfg.xml 文件中？
答: 在AEs中，綁定信息存儲在與每一個module 和EAR相關(guān)的xml文件中。這些文件叫做 ibm-type-bnd.xmi 在這里"type"指的是module的類型。例如，關(guān)于EJB的bindings 信息是存儲在EJB JAR包中叫做 ibm-ejb-bnd.xmi 的xml文件中。 應(yīng)用程序包安裝完成后，bindings信息不會位于 server-cfg.xml 中。它們?nèi)匀槐Ａ粼谠瓉淼膞mi文件中。
問: 在WebSphere高級版中，在企業(yè)應(yīng)用程序(EAR文件）安裝到應(yīng)用程序服務(wù)器上后，其bindings 信息是不是存儲在管理數(shù)據(jù)庫內(nèi)？如果在EAR安裝過程中，bindings信息做了一定的改變，那么改變過的信息將存儲在什么地方？
答:在EAR 文件安裝以前，bindings信息是儲存在 ibm-type-bnd.xmi 的文件中。在EAR 文件安裝到高級版的應(yīng)用程序服務(wù)器上后，bindings信息會存放到管理數(shù)據(jù)庫內(nèi)。在安裝過程中bindings信息做的任何改變 都會存放在管理數(shù)據(jù)庫內(nèi)，這些變化在 .xmi 文件里不會有任何顯示信息。
問: 從websphere3.5到4.0的移植過程會保存在admin.config文件中用戶所做的改變信息嗎?
答：任何存儲在WebSphere Version 3.5 的系統(tǒng)文件如admin.config 和bootstrap.properties 文件 中的信息都會保存在由 WASPreUpgrade() API所生成的備份目錄中，但是它們不會移植到4.0中。任何關(guān)于這些 文件的修改部分都必須手動的在4.0的相關(guān)文件里進行相應(yīng)的修改。
問:移植工具如何知道哪個應(yīng)用程序服務(wù)器需要移植？
答: WASPreUpgrade() API將會從WebSphere Application Server管理數(shù)據(jù)庫被導(dǎo)出一個完整的 XML文件，但是在移植過程中，只有本地節(jié)點上的應(yīng)用程序才會被升級到4.0中。
問: 動態(tài)緩存Dynamic Caching是不是HTTP_POST的緩存？結(jié)果是怎么樣的？
答: POST 與 GET 請求都能夠被緩存。在一個servlet內(nèi), 一個 POST參數(shù)是通過 HttpServletRequest.getParameter() , 方式來獲得的。POST變量在 servletcache.xml 文件中通過"parameter"標記來定義和表明。
問: 在WebSphere高級版本軟件包中所帶的SecureWay Directory是什么版本？
答:是 Secure Way Directory 3.2.6。
問: 在克隆一個應(yīng)用程序服務(wù)器時，是不是最初的原始應(yīng)用程序服務(wù)器必須是其中的一個克隆節(jié)點？
答: 是的。在WebSphere beta 版中允許選擇是否將原始的應(yīng)用程序服務(wù)器作為一個克隆節(jié)點，但是在GA版 中將不會有這個選項。在GA版中增加了一個功能，使得在同一個節(jié)點機器上的應(yīng)用程序服務(wù)器之間可以相互拷貝和移動運行在其上的應(yīng)用程序，這樣就會使得我們的原始應(yīng)用服務(wù)器的重建變得更加容易和方便。另外應(yīng)用程序數(shù)據(jù)和管理數(shù)據(jù)的分離存儲 也使得原始應(yīng)用服務(wù)器的重建變得更加容易。
問: 兩個Web modules 能不能有相同的上下文（context）目錄? (是不是在 AAT中 強制規(guī)定兩個Web modules 不能有相同的context目錄?)
答: AAT不會檢測兩個Web modules 是否擁有相同的context目錄，因為 這兩個modules 可以分別部署到不同的WebSphere管理域或者是同一個管理域上的不同虛擬主機 上。 WebSphere 本身不允許擁有相同的context 目錄的Web modules安裝在同一個虛擬主機上。在 beta 版中不會檢測在同一個虛擬主機上不同Web modules是否有相同的context目錄。但是在GA版中會檢測 同時不允許這種情況的存在。
問: 在高級版的軟件包CD中有什么東西?
答: 應(yīng)用程序服務(wù)器 CD (每個平臺一張CD - NT/2000, AIX, SUN, HP, and Linux)上有:
Secure Way Directory & DB2 (每個平臺一張CD - NT/AIX/SUN): Secure Way Directory 3.2.6
DB2 Enterprise Edition v7.2 CD2 (one platform per CD)
Client CD (NT/AIX/Sun)
Merant Server (所有的平臺共用一張CD )
Q: 為什么需要指定關(guān)于EJB 和企業(yè)應(yīng)用程序的安全角色？
答: 因為企業(yè)應(yīng)用程序中的 EJBModule 和 WebModule 可能是由不同的程序員來獨立開發(fā)完成的（可能來自不同的公司），而在開發(fā)這些組件時，他們肯定會定義一些通過授權(quán)的角色。因此，模塊開發(fā)人員會將這些不同的角色定義加入到相關(guān)的配置描述符（deployment descriptor） 文件中。
然后，不同的 modules 可能會裝配到一個應(yīng)用程序中(可能是通過 另外的應(yīng)用程序裝配者來完成，而他不會改變這些原始模塊的任何內(nèi)容）我們必須保證在同一個應(yīng)用程序內(nèi)的不同模塊所定義的角色必須是合理的，也就是不存在這些模塊之間可能存在的角色定義重復(fù)的問題。所以我們在從module到應(yīng)用程序級的轉(zhuǎn)換中必須有 "role push-up"來定義解決
同樣，應(yīng)用程序裝配人員可能會定義一些關(guān)于整個應(yīng)用程序的新的角色，這些角色的定義信息是保存在應(yīng)用程序的配置描述符文件中。我們不知道那些模塊可能會與這些角色相關(guān)，因此這些角色定義信息將會保存在應(yīng)用程序的deployment descriptor文件中以供使用。
問: 請描述一下在ORB plug-in級的EJB WLM管理？
答: 我們考慮存在一個EJBClient,幾個EJB 克隆和一個管理服務(wù)器的情況。
在管理服務(wù)器中保存著可用的克隆節(jié)點的列表,同時這個列表用一個epoch數(shù)字來 標記。管理服務(wù)器是克隆節(jié)點的父進程，當其管理的克隆中有一個當?shù)魰r，在管理服務(wù)器里會標明。同時 管理服務(wù)器會周期性的pings其管理的每個clone節(jié)點，如果在一定的時間內(nèi)克隆節(jié)點沒有響應(yīng)（可以自己配置） 那么管理服務(wù)器會認為該節(jié)點已經(jīng)當機。每次當節(jié)點生效或者是失效時，管理服務(wù)器都會更新它的克隆列表 同時為這個列表生成一個新的epoch數(shù)值。這個列表會被發(fā)送到每個克隆接點以及其他的遠端管理服務(wù)器上。
當EJBClient為所需要的EJB做JNDI查找時，管理服務(wù)器將返回這個EJB的home接口。home接口中包括可用的EJB 克隆的列表以及列表的epoch數(shù)值。當客戶端調(diào)用ejbcreate, a finder method等方法時,ORB將從 列表中選擇其中的一個EJB克隆，同時將請求信息和列表的epoch數(shù)值一塊傳送到選擇的克隆上。
如果一個克隆失效了，那么下一個ejbcreate, finder, 等的請求將可能出現(xiàn)下面兩種情況之一:
問: 關(guān)于CICS 和 MQSeries 的連接器是否可以使用J2C?
答: 在CICS 中可以使用J2C。目前在MQSeries中還不支持這個標準。
問: 是不是在WebSphere 4.0中已經(jīng)沒有關(guān)于OSE 遠程調(diào)用的支持？
答: 現(xiàn)在的情況是在WebSphere4.0中已經(jīng)不再支持使用OSE協(xié)議。我們可以支持在 同一個服務(wù)器上同時運行webshere 3.5的0SE和4.0的HTTP協(xié)議。但是當你與WebSphere 4.0的應(yīng)用程序服務(wù)器通信時必須使用HTTP transport 。
問: WebSphere 4.0 支持Oracle‘s 8.1.7的 JDBC driver嗎？
答: 是的，在WebSphere 4.0高級版和AEs中都支持Oracle 8.1.7。
問: WebSphere 4.0 支持 VisualAge for Java 3.5 中開發(fā)的Persistence Builder 對象嗎？
答: WebSphere 4.0 不支持。
問: BeanCache是什么意思？
答: Bean Cache 是WebSphere 4.0 中一個關(guān)于提高性能的特性。它指的是將 bean 存放在系統(tǒng)內(nèi)存內(nèi)，使得在每次使用EJB的時候不需要重新裝載bean的實例。
Bean caching 選項是通過在AAT中 AAT => Entity Bean => IBM extension =>來指定Bean Cache。
Bean Cache --- Entity Beans
| 激活點: | 裝載調(diào)用點: | |
| ONCE | ACTIVATION | = Commit Option A |
| ONCE | TRANSACTION | = Commit Option B |
| TRANSACTION | TRANSACTION | = Commit Option C |
Bean Cache --- Stateful Session Beans
| 激活點: | |
| ONCE | = bean一般是位于Active Cache中，直到緩沖池已滿或者是超時 |
| TRANSACTION | = 在交易開始/提交完成時生效或者是失效。 |
問: Session Affinity是不是主機的IP 地址?
答: Session Affinity機制是基于指定的瀏覽器實例的。因此，如果你在同一個客戶機上有兩個瀏覽器，那么每個瀏覽器都有它自己相應(yīng)的session。
問:WebSphere 4.0 是否支持Jetace?
答: 不支持。在WebSphere 4.0中， Jetace 已經(jīng)被Application Assembly Tool所取代。
問: WebSphere 4.0 是否支持JPDA?
答: 是的。JTPA是JDK1.3的一部分。而我們的WebSphere 4.0支持的是JDK1。3。
問: 如果一個應(yīng)用程序沒有使用EJB，那么如何保證Java Class的方法的安全性?
答: 一般情況下,用戶只會調(diào)用位于應(yīng)用程序服務(wù)器上的Servlet, JSP, EJB 或者是靜態(tài)資源文件。 不會存在對于 Java Class的直接調(diào)用。一般都是通過一個EJB或者是servlet來調(diào)用相應(yīng)的Java class 。因此，對Java class 的保護可以通過對相關(guān)的EJB或者 servlet實施保護來間接實現(xiàn)。
問: 怎樣在DB2中重建WAS數(shù)據(jù)庫?
答:首先需要 Drop 存在的 WAS 數(shù)據(jù)庫。 (使用db2cmd 命令行方式或者是使用DB2的控制中心。)
db2cmd
db2 drop db was
然后建立新的數(shù)據(jù)庫：
db2 create dB was
db2 update dB cfg for was using applheapsz 256
將WebSphere\appserver\bin目錄下的 admin.config 文件做如下修改:
install.initial.config=true
# Create AdminServer database tables
com.ibm.ejs.sm.adminServer.createTables=true
問: 如何為CMP Entity Bean設(shè)置相應(yīng)的數(shù)據(jù)庫?
答: 你可以在AAT中，在entity bean操作中為 CMP entity bean 設(shè)置相應(yīng)的數(shù)據(jù)庫，或者是設(shè)置為關(guān)于整個EJB module的缺省數(shù)據(jù)庫。如果一個CMP entity bean 沒有指定任何相應(yīng)的數(shù)據(jù)庫，那么它將會使用缺省數(shù)據(jù)庫。 可是，如果在CMP Entity bean 中指定的DataSource，那么缺省的DataSource名字將不會有任何作用，對于CMP Entity bean 本身來說。注意，指定的JDBC DataSource 的JNDI名必須在管理控制臺有相應(yīng)的配置。
問: CCF (Common Connector Framework) 是不是會被J2C所代替?
答: 最初的CCF是由VisualAge for Java 團體所開發(fā)的一項IBM的專有技術(shù)， 后來IBM將這項技術(shù)貢獻給了Java standards組織。J2EE Connector 規(guī)范(J2C), 關(guān)于Java 規(guī)范的說明書， 是這項技術(shù)的最終聲明。因此CCF從表面上來說會不再存在，但是實際上與J2EE標準是一致的。
問: WebSphere 4.0 Enterprise Edition 中包括TX Series嗎?
答: WebSphere 4.0和3.5的企業(yè)版中都包括TX Series。
問: WebSphere 4.0 EE 版中是否有一個獨立于Business Rule Beans的 rules-engine?
答: 在企業(yè)版中實現(xiàn)的唯一的規(guī)則技術(shù)是Business Rules Beans - 它不是實現(xiàn)在AI(人工智能)中所說的 rule-based engine (既從一系列的規(guī)則中發(fā)現(xiàn)新的知識） BRBs 是一個方法用來客觀的確認或者是"derivation" (calculation) 某種算法, 通過這種方式 使得我們可以很容易的修改在你的應(yīng)用程序中的一些行為方式或準則(通過一些管理配置而不是編程)。
問: 如果用戶想要將 MS SQL 作為他的應(yīng)用數(shù)據(jù)庫，那么用戶是否可以從Merant公司 購買相關(guān)的Merant drivers并將它安裝到AEs上?
答: 顧客可以從Merant公司購買相應(yīng)的drivers,同時安裝它們與AES一塊協(xié)同工作。但是IBM 不建議與支持顧客使用這種配置。
問: 在遠程機器上運行LaunchClient命令需要什么？ (也就是，所需要的JVM在什么地方）
答: 這需要WebSphere的客戶端容器(client container)的安裝。這個安裝將會把JVM和其他所有 需要的 WebSphere類文件安裝到遠程客戶機上。
問: WAS 4.0 能使用其它廠商的JNDI目錄服務(wù)嗎？
WebSphere 能夠在其它廠商的JNDI目錄服務(wù)器上實現(xiàn)JNDI查找。然而，部署在WebSphere上的 EJB仍將注冊在WebSphere的內(nèi)部JNDI命名空間內(nèi)，這是不可以被配置修改的。
問: XMLConfig 能否實現(xiàn)對多個服務(wù)器組和克隆的管理？
答: 可以實現(xiàn)這種管理。
問: 將來 XMLConfig 和 WSCP 這兩種管理方式功能會不會更加接近？
答: XMLConfig 和 WSCP 這兩種工具是用來實現(xiàn)兩個不同的相互分離的任務(wù)。 XMLConfig 設(shè)計用來實現(xiàn)服務(wù)器配置信息的改變，例如建立或修改服務(wù)器組。 WSCP 是設(shè)計用來 實現(xiàn)進一步的操作，比如說開始或停止某些對象的運行以及完成一些腳本定義的任務(wù)。在WSCP中能夠調(diào)用XMLConfig 工具。
問: 在VisualAge for Java 4.0 是否有WebSphere 4.0的測試環(huán)境WebSphere Test Environment (WTE) ?
答: 沒有,因為在VisualAge for Java 4.0 中的JDK版本仍然是1.2.2 SR9 ,因此其內(nèi)嵌的WTE 不能同步升級到4.0. 在我們的應(yīng)用部署到生產(chǎn)環(huán)境前，可以使用WAS AEd來進行應(yīng)用程序的測試。
問: WebSphere 能否使用 JNDI作為其用戶的注冊表來進行身份認證？
答: 可以，在你的身份認證機制使用pluggable user registry表時，你需要 實現(xiàn)一些pluggable user registry 定義中所支持的一些必須的接口API，同時你也可以從其他合適的地方包括JNDI服務(wù)器中獲得一些相應(yīng)的認證信息。
問: XMI 是代表什么意思？
答: XMI代表XML Metadata Interchange也就是XML元數(shù)據(jù)交換。
問: 在WebSphere4.0高級版中是否會和AEs版一樣有基于web方式的管理控制臺?
答: 目前在WebSphere4.0高級版中沒有計劃推出基于瀏覽器方式的管理控制臺。高級版中用其它的工具，命令行的XMLConfig 和 WSCP方式來實現(xiàn)管理控制臺的功能。
問: 在WebSphere 4.0高級版的軟件包中是否包括MQSeries ?
答: 沒有在WebSphere高級版以及 AEs 4.0或者是AEd 4.0軟件包中沒有包括MQSeries 。
問: 在WebSphere 4.0中所支持的XML 技術(shù)包括那些( XERCES, XALAN)?
答:包括 XML 4J 3.1.1 => Xerces 1.2.1
XSL 2.0 => Xalan 2.0。
問: 如果你手動的在EJB中拋出一個異常,在EJB客戶端中能否接收到這個異常信息？
答: 可以。如果使用EJBs,那么出現(xiàn)的異常信息一般都會在客戶端也有顯示。
問: 請列出設(shè)置多節(jié)點的WebSphere管理域的方法(使用DB2)
答: 假定你已經(jīng)在其中的一臺機器上建立了WAS管理數(shù)據(jù)庫。
在DB2的客戶機上(遠程的WebSphere 節(jié)點), 做下列的操作： db2 catalog tcpip node <db2 node name> remote <remote-node> server db2cdb2
例如：: db2 catalog tcpip node WSNode1 remote WSNode1.rchland.ibm.com server db2cdb2
db2cdb2 是在 \winnt\system32\drivers\etc\services 文件中的入口點設(shè)置，例如： db2cdb2 50000/tcp
或者在"services" 文件中設(shè)置監(jiān)聽端口為50000的合適的服務(wù)名。
如果在你的客戶機上只安裝了DB2客戶端，那么你可能需要在服務(wù)文件中輸入相應(yīng)的 db2cdb2 入口。
這樣在你的DB2控制中心上將會出現(xiàn)你已經(jīng)設(shè)置過的遠程節(jié)點。 db2 catalog dB <remote dB name> as <local alias name> at node <db2 node name>
比如說: db2 catalog dB was as was2 at node WSNode1
你將看到在你的遠程節(jié)點上會出現(xiàn)別名為WAS2的遠程WAS管理數(shù)據(jù)庫。
在 admin.config 文件中做下列的改變:
將管理數(shù)據(jù)庫的名字改變?yōu)槟闼O(shè)置的數(shù)據(jù)庫別名(在我們的例子中是was2): com.ibm.ejs.sm.adminServer.dbdatabaseName=was2 .
如果你需要建立數(shù)據(jù)庫的初始配置信息，那么需要將 install.initial.config=true .
修改為 com.ibm.ejs.sm.adminServer.createTables=false .
如果你將這個值設(shè)為"true," 那么它代表將重建你的WAS管理數(shù)據(jù)庫中的所有表，因此，除非你有這個必要，否則我們不要把這個值設(shè)為"true,"。
問: PMI (性能監(jiān)測基礎(chǔ)平臺)是否在WebSphere高級版和AEs版中都支持?
答: PMI 只能在WebSphere高級版本中使用。在AEs中沒有這個工具支持。
問: 可不可以通過一個Java API來啟用關(guān)于PMI Instrumentation 的支持？
答: 我們只能通過管理控制臺或者是資源分析器Resource Analyzer來啟用關(guān)于PMI instrumentation 的支持，目前我們不支持通過Java API 來啟用PMI instrumentation 。
問: PMI instrumentation 級定義是否可以設(shè)置到關(guān)于EJBs 和 servlets的方法級?
答: PMI instrumentation 可以設(shè)置到EJB 的方法級別。而對于servlets來說, PMI instrumentation 只能設(shè)置到servlet層次，而不能設(shè)置到關(guān)于這個servlet所調(diào)用的方法。
