我的郵箱中有一個bug報告。它報告了在Weblogic server環境中的Hibernate和Kodo之間切換JPA持久性提供者時的一個問題。在再現這個bug的過程中,我學到了一些知識,包括如何在Weblogic Server 10.0中安裝Hibernate,以及如何使用一個特定的持久性提供者X部署基于JPA的Web應用程序,然后再使用另一個持久性提供者Y重新部署它而不會使整體(指Weblogic Server)崩潰。
這次經歷促使我在一段停頓之后又開始了文章寫作(New Yorker雜志的一幅 漫畫 觸發了我的寫作靈感)。
總之,這篇文章將:
描述在Weblogic Server 10.0中安裝和配置Hibernate的工作過程
解答為何不必在Weblogic Server 10.0中安裝Kodo或OpenJPA
展示一個非常簡單的基于無狀態會話Bean的服務的例子,并演示在Weblogic Server運行狀態下在Hibernate、OpenJPA和Kodo之間切換JPA提供者的步驟
再現產生問題的bug,不僅是因為報告者認為這很嚴重,在經過簡短的實驗之后,我也認為如此
介紹這個bug如何造成應用服務器環境中JPA引導的變化
測試提供者切換的一個非常簡單的方法
我使用了一個簡單的服務來檢驗是否使用了正確的提供者并且運行無誤――雖然只是初步的持久性操作。這個簡單的服務接口(我將基于它進行測試)如下所示:
JPAService.java
01 package service;
02 /**
03 * A very simple service to verify the persistence provider being used.
04 * The service also can persist a simple log message in a database.
05 *
06 * @author ppoddar
07 *
08 */
09 public interface JPAService {
10 /**
11 * Returns the name of the active provider.
12 */
13 public String getProvider();
14
15 /**
16 * Logs the given message.
17 *
18 * @param message an arbitray message string.
19 *
20 * @return a Message instance that has been persisted. The service will
21 * attach a timestamp to the message.
22 */
23 public Message log(String message);
24 }
關于這個服務將如何實現還不明確;甚至沒有說明它將使用JPA。這就是服務定義應有的方式――實現技術的不明確性(這里省略了通常的 IMO――這是我的觀點――也許是謙虛的,也許恰恰相反)。
基于JPA和會話Bean的應用程序入門
我將簡短地討論一下如何在使用JPA的無狀態會話Bean中實現這個服務。這是相當基本的知識。如果您已經熟悉JPA,可以直接跳到 下一節。