2009-12-05 87 views
3

我得到這個錯誤:servlet異常+類轉換異常+ Glassfish的+ Netbeans的+ JPA實體+ Vaadin

StandardWrapperValve [Vaadin的Servlet]:PWC1406:Servlet.service()進行的servlet Vaadin的Servlet拋出異常 的java .lang.ClassCastException:com.delhi.entities.Category不能轉換爲com.delhi.entities.Category

當我嘗試在glassfish v2上運行我的webapps時。

類別是JPA實體對象

有問題的代碼根據服務器日誌:

List<Category> categories = q.getResultList(); 

任何想法出了什麼問題:

for (Category c : categories) { 
      mymethod(); 
    } 

類別源自?

回答

1

這是一個類加載器問題。如果一個類由不同的類加載器加載,則不能將對象分配給對方。您可能已經將一個對象從一個WAR傳遞到另一個。有幾個選項可以解決這個問題:

  • 將所有代碼放入一個WAR中。
  • 在WAR之間使用某種形式的遠程處理。序列化處理類加載器問題。
  • 試着把你所有的WAR放到一個EAR中。如果這不起作用,請將所有代碼放入MANIFEST.MF中EAR類路徑中的JAR。
0

我的觀察是,它只發生在使用熱重新部署或靜態重新部署時。當然,這隻適用於在類和類都相同的情況下得到類轉換異常。

解決方法:

  • 不要取消部署和部署,而不是重新部署
  • 重新啓動應用服務器
  • 刪除受影響的類
  • 使用遠程接口的靜態成員(序列化使這個去)

IMO我認爲類加載器無法重新加載類和舊版本被重用,導致錯誤。


This article不談論這個錯誤直接,但它是在類加載器是如何工作的良好背景資料。

0

Glassfish v2和Glassfish v3也遇到了這個問題。

我可以問你一個問題:當應用程序部署時(通過啓動時加載的servlet或上下文偵聽器),你是否試圖初始化任何持久對象?

bguiz,我注意到這個問題只發生在重新部署。對新近重新啓動的Glassfish服務器的全新部署從未遇到過這個問題。

就像FelixM提到的,我確信這是一個類加載器問題,但我不認爲這是多個戰爭的問題(我只有1個部署到我的服務器)。在Glassfish 3中,我可以看到我的WAR正在使用2個Glassfish「引擎」。一個用於網絡(戰爭),另一個用於jpa。據我所知,這些是不同的容器,每個容器都有自己的類加載器。我猜Glassfish v2的工作方式是一樣的。

我正在使用Spring並(重新)初始化(重新)部署一些持久對象。我在想,當Web引擎重新開始戰爭時,jpa引擎仍在使用舊的類定義。通常情況下,如果在初始失敗後重試重新部署,它可能會成功(有時可能需要多次重試,但最終無需重新啓動即可成功 - Glassfish v3取得比v2更好的成功)。

在這一點上,我想這兩個類加載器是不同步的,或者在重新部署時存在某種競爭條件,允許此操作有時會成功。我試圖強制類加載器,編寫這樣的代碼

HashMap<Object, Object> properties = new HashMap<Object, Object>(); 
properties.put(PersistenceUnitProperties.CLASSLOADER, this.getClass().getClassLoader()); 
entityManagerFactory = Persistence.createEntityManagerFactory(jpaContext, properties); 

但它似乎沒有任何影響。

我也想知道如果在啓動時消除初始化可以解決問題,給appserver時間使用任何jpa類之前重新同步兩個引擎(這就是爲什麼我問我的後續問題)。

0

我曾經有過同樣的問題,我有環境是以下幾點:

  • 我Glassfish的V4
  • NetBeans支持以下項目
    • 含網頁戰項目實體
    • 和耳朵項目與網頁戰爭項目

問題是,在戰爭的項目設置中,我檢查了[x] 運行>部署保存。這是導致部署戰爭項目我每次擊中保存。有時會導致PermGen(內存)問題和無法正確部署EAR(因爲例如在取消部署和部署EAR之間 - 這個「瘋狂」的Netbeans部署這場戰爭)。

解決方案:如果Netbeans的& &使用EAR,然後取消部署上的保存在項目屬性。

編輯:

看來,這個錯誤與

SEVERE: The web application [/faces] created a ThreadLocal with key of type [org.glassfish.pfl.dynamic.codegen.impl.CurrentClassLoader$1] (value [[email protected]a63a]) and a value of type [org.glassfish.web.loader.WebappClassLoader] (value [WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.