4

次のエラーが表示されます。

StandardWrapperValve[Vaadin Servlet]: PWC1406: Servlet.service() for servlet Vaadin Servlet が例外 java.lang.ClassCastException をスローしました: com.delhi.entities.Category は com.delhi.entities.Category にキャストできません

Glassfish v2でWebアプリケーションを実行しようとすると.

カテゴリは JPA エンティティ オブジェクトです

サーバーログによると、問題のコードは次のとおりです。

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

カテゴリは次から派生します。

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

何がうまくいかなかったのですか？

4

5 に答える 5

1

今日も同じ問題がありました。ソリューションは、使用後に EntityManagerFactory を閉じていました。
この答えは私を助けました: https://stackoverflow.com/a/13823219/2455506

于 2015-03-23T12:44:45.900 に答える
1

私はかつて同じ問題を抱えていましたが、私が持っていた環境は次のとおりでした：

  • 私はGlassfish v4を持っていました
  • 次のプロジェクトの NetBeans
    • エンティティを含む web ページ戦争プロジェクト
    • そしてそのウェブページ戦争プロジェクトでプロジェクトを耳にする

問題は、戦争のプロジェクト設定で [x] Run>Deploy on saveをチェックしたことでした。これにより、 save を押すたびに戦争プロジェクトが展開されていました。PermGen (メモリ) の問題が発生し、EAR を正しくデプロイできなくなることがありました (たとえば、EAR のアンデプロイとデプロイの間に、この「クレイジーな」Netbeans がこの戦争をデプロイしていたため)。

解決策: EAR を使用する Netbeans && の場合は、プロジェクトのプロパティで [保存時にデプロイ] をオフにします。

編集：

このエラーが関連しているようです

SEVERE:   The web application [/faces] created a ThreadLocal with key of type [org.glassfish.pfl.dynamic.codegen.impl.CurrentClassLoader$1] (value [org.glassfish.pfl.dynamic.codegen.impl.CurrentClassLoader$1@249ea63a]) 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.
于 2014-05-06T19:00:37.383 に答える
0

私の観察では、ホット再デプロイまたは静的再デプロイを使用している場合にのみ発生します。もちろん、これは、to クラスと from クラスの両方が同じクラス キャスト例外が発生した場合にのみ適用されます。

回避策:

  • 再デプロイの代わりにアンデプロイとデプロイを使用しないでください
  • アプリサーバーを再起動する
  • 影響を受けるクラスの静的メンバーを削除します
  • リモート インターフェイスを使用する (シリアル化により、これはなくなります)

IMOクラスローダーがクラスをリロードできず、古いバージョンが再利用されたため、エラーが発生したと思います。

この記事では、このエラーについて直接説明していませんが、クラス ローダーの動作に関する優れた背景情報です。

于 2010-06-01T12:41:44.007 に答える
0

Glassfish v2 と Glassfish v3 でもこの問題が発生しています。

質問をしてもよろしいですか:アプリケーションのデプロイ時に (起動時にロードされたサーブレットまたはコンテキスト リスナーを介して) 永続化オブジェクトを初期化しようとしていますか?

bguizと同様に、この問題は再デプロイ時にのみ発生することに気付きました。新しく再起動した Glassfish サーバーへの新しいデプロイでは、この問題は発生しません。

FelixMが述べたように、これはクラス ローダーの問題であると確信していますが、複数の戦争の問題ではないと思います (サーバーにデプロイされているのは 1 つだけです)。Glassfish 3 では、WAR が 2 つの Glassfish "エンジン" を利用していることがわかります。1 つは Web (戦争) 用で、もう 1 つは jpa 用です。私が理解していることから、これらはそれぞれ独自のクラスローダーを持つ異なるコンテナーです。Glassfish v2 も同じように動作すると思います。

私はSpringを使用しており、（再）デプロイ時にいくつかの永続オブジェクトを（再）初期化しています。私が考えているのは、Web エンジンが戦争を再初期化している間、jpa エンジンはまだ古いクラス定義を使用しているということです。多くの場合、この最初の失敗の後に再デプロイを再試行すると、成功する場合があります (複数回の再試行が必要になる場合もありますが、最終的には再起動せずに成功することができます - v2 よりも Glassfish v3 の方が成功しています)。

この時点で、これら 2 つのクラスローダーが同期していないか、再デプロイ時にある種の競合状態が発生して、この操作が成功することがあると考えています。このようなコードを書いて、クラスローダーを強制しようとしました

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

しかし、それは何の影響も与えていないようでした。

また、起動時の初期化をなくすことで問題が解決し、jpa クラスを使用する前に両方のエンジンを再同期する時間を appserver に与えることができるかどうかも疑問に思っています (これが、フォローアップの質問をした理由です)。

于 2010-07-02T13:54:29.327 に答える