1

GWTでJPAを使用しようとしています。

私のserviceImpl呼び出し

UserDAO.exists(user);

同じメソッドを同じパラメーターで呼び出すテスト ケースを実行すると、正常に実行されます。RPC 呼び出しを行うと、ひどく失敗した場合 (最後にエラー)。

persistence.xml の名前を someothername.xml に変更すると、同じエラーが発生するため、GWT (開発モード BTW) が私の persistence.xml を読み取っていないと考える傾向があります。

エラー:

Starting Jetty on port 8888
   [WARN] Exception while dispatching incoming RPC call
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract hobarrera.client.dto.main.UserRegDTO hobarrera.client.services.AuthService.selfRegisterUser(java.lang.String,java.lang.String,java.lang.String,java.lang.String) throws hobarrera.client.exceptions.MyCustomizedException' threw an unexpected exception: java.lang.ExceptionInInitializerError
 at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:378)
 at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:581)
 at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188)
 at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224)
 at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
 at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
 at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
 at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
 at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
 at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:49)
 at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:324)
 at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
 at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
 at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
 at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
Caused by: java.lang.ExceptionInInitializerError
 at hobarrera.server.DAO.EntityManagerFactory.createEntityManager(EntityManagerFactory.java:13)
 at hobarrera.server.DAO.UsuarioDAO.userNameExists(UsuarioDAO.java:52)
 at hobarrera.server.services.AuthServiceImpl.selfRegisterUser(AuthServiceImpl.java:60)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:562)
 ... 22 more
Caused by: javax.persistence.PersistenceException: No resource files named META-INF/services/javax.persistence.spi.PersistenceProvider were found. Please make sure that the persistence provider jar file is in your classpath.
 at javax.persistence.Persistence.findAllProviders(Persistence.java:167)
 at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:103)
 at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
 at hobarrera.server.DAO.EntityManagerFactory$RealEntityManagerFactoryContainer.<clinit>(EntityManagerFactory.java:9)
 ... 30 more
[ERROR] 500 - POST /desarrollonew/greet (0:0:0:0:0:0:0:1) 57 bytes
   Request headers
      Host: localhost:8888
      User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100216 Fedora/3.5.8-1.fc12 Firefox/3.5.8
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
      Accept-Language: en-us,en;q=0.5
      Accept-Encoding: gzip,deflate
      Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
      Keep-Alive: 300
      Connection: keep-alive
      Referer: http://localhost:8888/desarrollonew/hosted.html?desarrollonew
      Cache-Control: no-cache
      X-GWT-Permutation: HostedMode
      X-GWT-Module-Base: http://localhost:8888/desarrollonew/
      Content-Type: text/x-gwt-rpc; charset=utf-8
      Content-Length: 187
      Pragma: no-cache
   Response headers
      Content-Type: text/plain

[編集]
GWTには独自のpersistence.xmlファイルがあるようです(内部使用のためだと思います)。そのため、persistence.xml の名前を somethingelse.xml に変更しても、同じエラーが発生しました。読み込まれている persistence.xml ファイルは常に GWT のものでした。

だから今、私の質問は次のとおりです。どうすればそれをオーバーライドしたり、別のものを強制的に使用したり、それなしで生活したりできますか?

4

4 に答える 4

2

に DataNucleus jar がありWEB-INF/libますか?

于 2010-03-06T22:55:41.383 に答える
0

参照:http ://code.google.com/webtoolkit/articles/using_gwt_with_hibernate.html

Hibernateオブジェクトがブラウザーの世界に到達したときに理解できないのはなぜですか?

では、何がうまくいかなかったのでしょうか。ホストモードコンソールを見ると、「着信RPC呼び出しのディスパッチ中に例外が発生しました」という警告メッセージがコンソールに記録されていることがわかります。警告メッセージを選択すると、下のペインにかなり長いスタックトレースが表示されます。

これは注意を払うべき部分です:

原因:com.google.gwt.user.client.rpc.SerializationException:タイプ'org.hibernate.collection.PersistentSet'が、このSerializationPolicyによってシリアル化できるタイプのセットに含まれていないか、そのクラスオブジェクトをロードできませんでした。セキュリティ上の理由から、このタイプはシリアル化されません。com.google.gwt.user.server.rpc.impl.StandardSerializationPolicy.validateSerialize(StandardSerializationPolicy.java:83)at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:591)

ここで重要なのは、アカウントのロードと取得を試みたときにスローされたSerializationExceptionです。

では、正確には何が悪かったのでしょうか。さて、GWT RPCドキュメントで読んだかもしれませんが、RPCを介して転送されたタイプが「シリアル化可能」でない場合は常にSerializationExceptionがスローされます。ここでのシリアライズ可能の定義は、GWT RPCメカニズムが、タイプをバイトコードからJSONに、またはその逆にシリアル化および逆シリアル化する方法を知っていることを意味します。型をGWTコンパイラにシリアル化可能として宣言するには、RPCを介して転送される型に、特にこの目的のために作成されたIsSerializableインターフェイスを実装するか、そのメンバーとメソッドがあれば、標準のjava.io.Serializableインターフェイスを実装します。シリアル化可能なタイプで構成されます。

AccountオブジェクトとRecordHibernateオブジェクトの場合、Serializableインターフェイスを実装しているので、これらは機能するはずですよね。結局のところ、悪魔は細部に宿っています。

オブジェクトを取得してHibernateオブジェクトに変換すると、オブジェクトが拡張されて永続化されるようになりました。その永続性は、オブジェクトのある種のインストルメンテーションなしでは実現できません。Hibernateの場合、Javassistライブラリは、これらのオブジェクトのバイトコードを永続エンティティによって実際に置き換えて書き換え、Hibernateの魔法を機能させます。これがGWTRPCにとって意味することは、オブジェクトをネットワーク経由で転送する準備ができるまでに、実際にはコンパイラが転送しようとしていると考えていたオブジェクトと同じではないため、逆シリアル化しようとすると、GWTRPCメカニズムがタイプが何であるかをもはや知らず、それを逆シリアル化することを拒否します。

実際、以前のloadAccounts()の呼び出しを詳しく調べて、RPC.invokeAndEncodeResponse()メソッドにステップインすると、逆シリアル化しようとしているオブジェクトが、次のアカウントタイプのArrayListになっていることがわかります。それらのjava.util.Setのレコードはorg.hibernate.collection.PersistentSetタイプに置き換えられました。

同様の問題は、GoogleAppEngineで使用されるJDOやJPAなどの他の永続性フレームワークでも発生します。

考えられる解決策は、サーバー側のRPC呼び出しを介して戻る前に、タイプをもう一度反対方向に置き換えることです。これは実行可能であり、ここで発生した問題を解決しますが、まだ害を及ぼすことはありません。Hibernateを使用するもう1つの大きな利点は、必要なときに関連するオブジェクトを遅延ロードできることです。たとえば、サーバー側では、アカウントを読み込んで変更し、account.getRecords()の呼び出しとそれらのレコードに対する何らかのアクションが実行されたときにのみ、関連するレコードを読み込むことができます。特別なHibernateインストルメンテーションは、呼び出し時に実際にレコードをフェッチし、本当に必要な場合にのみレコードを使用できるようにします。

ご想像のとおり、これは、これらのHibernateオブジェクトがJavaサーバー側からブラウザーランドに移動したGWTRPCの世界での奇妙な動作に変換されます。GWT RPCサービスがアソシエーションに遅延アクセスしようとすると、LazyInitializationExceptionのようなものがスローされる場合があります。

于 2011-04-05T12:48:22.817 に答える
0

クラスパスに JPA 実装を追加していません。クラスパスに datanucleus (またはトップリンク、または使用しているもの) の jar を配置します。これにより、エンティティ マネージャーの作成が処理されます。

于 2010-03-06T22:43:08.303 に答える
-1

これは GWT の外部サーバーへの切り替えを提案する n 回目のようなものなので、以前の回答を引用させてください (GWT に組み込まれた Jetty の問題の詳細な説明については、完全な回答をお読みください)。

外部 Java サーバー (Tomcat など、インストール済みで、構成で動作するようです) に切り替えることをお勧めします。GWT に付属している不自由な Jetty を使用するよりも、はるかに問題が少なく、簡単です。

手順はドキュメントにあります。GWT の Jetty を使い続けると、今後さらに多くの問題に遭遇することになります。

ただし、GWT に付属する Jetty には問題があることが知られています。GWT(簡単な手順、IMHO)で外部サーバーを使用する方法の説明については、ドキュメントを読んでください-奇妙なエラー/例外による欠点や問題はありません。

于 2010-03-07T02:01:56.053 に答える