JPA 和 GWT 失败

Question

我正在尝试将 JPA 与 GWT 一起使用。

我的 serviceImpl 调用

UserDAO.exists(user);

当我运行一个测试用例时，它调用相同的方法，使用相同的参数，它运行正常。当我进行 RPC 调用时，如果严重失败（最后出错）。

当我将 persistence.xml 重命名为 someothername.xml 时，我得到了 SAME 错误，所以我倾向于认为 GWT（顺便说一句在开发模式下）没有读取我的 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 的。

所以现在我的问题是：我如何覆盖它，强制使用另一个，或者没有它？

Answer 1

WEB-INF/lib 中有 DataNucleus 罐子吗？

Answer 2

您没有在类路径中添加 JPA 实现。将 datanucleus（或 toplink，或您正在使用的任何东西）的 jar 放在您的类路径中，它负责创建实体管理器。

Answer 3

参考：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) 在 com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:591)

这里的关键是我们尝试加载和检索帐户时引发的 SerializationException。

那么到底出了什么问题？好吧，正如您可能在 GWT RPC 文档中读到的那样，只要通过 RPC 传输的类型不是“可序列化的”，就会引发 SerializationException。这里对serializable 的定义意味着GWT RPC 机制知道如何将类型从字节码序列化和反序列化为JSON，反之亦然。要向 GWT 编译器声明一个类型为可序列化的，您可以使要通过 RPC 传输的类型实现 IsSerializable 接口，特别是为此目的创建的，或者实现标准的 java.io.Serializable 接口，前提是它的成员和方法由也可序列化的类型组成。

对于 Account 和 Record Hibernate 对象，我们正在实现 Serializable 接口，所以它们应该可以工作，不是吗？事实证明，魔鬼在细节中。

当您将一个对象转换为 Hibernate 对象时，该对象现在被增强为持久性。如果没有某种类型的对象检测，这种持久性就不会出现。在 Hibernate 的情况下，Javassist 库实际上用持久实体替换和重写这些对象的字节码，以使 Hibernate 发挥神奇的作用。这对 GWT RPC 意味着，当对象准备好通过网络传输时，它实际上并不是编译器认为将要传输的对象，因此在尝试反序列化时，GWT RPC 机制不再知道类型是什么并拒绝反序列化它。

事实上，如果你更深入地查看之前对 loadAccounts() 的调用，并进入 RPC.invokeAndEncodeResponse() 方法，你会发现我们试图反序列化的对象现在变成了一个 ArrayList将其 java.util.Set 记录替换为 org.hibernate.collection.PersistentSet 类型的帐户类型。

Google App Engine 上使用的其他持久性框架（例如 JDO 或 JPA）也会出现类似问题。

一个潜在的解决方案是在通过服务器端 RPC 调用返回之前再次以相反的方向替换类型。这是可行的，并且会解决我们在这里遇到的问题，但我们还不会受到伤害。使用 Hibernate 的另一个好处是我们可以在需要时延迟加载关联的对象。例如，在服务器端，我可以加载一个帐户，对其进行更改，并且仅在调用 account.getRecords() 并对这些记录执行某些操作时才加载其关联记录。特殊的 Hibernate 工具会在我拨打电话时负责实际获取记录，仅在真正需要时才可用。

正如您可能想象的那样，这将转化为 GWT RPC 世界中的奇怪行为，这些 Hibernate 对象从 Java 服务器端传输到浏览器区域。如果 GWT RPC 服务尝试延迟访问关联，您可能会看到类似 LazyInitializationException 被抛出。

Answer 4

由于这是我第 n 次建议为 GWT 切换到外部服务器，所以让我引用 my previous answer（请阅读完整答案以更深入地解释 GWT 的嵌入式 Jetty 问题）：

我建议只是切换到 外部 Java 服务器（如 Tomcat， 您似乎已经安装了 适用于您的配置） - 问题少得多，比尝试容易 与残废的码头一起工作 自带 GWT。

说明可以在 文档。如果你坚持使用 GWT 的 Jetty， 你只会遇到更多的问题 未来。

不过，这仍然是事实 - GWT 附带的 Jetty 众所周知是有问题的。通读docs，了解如何将外部服务器与 GWT 一起使用（简单程序，恕我直言） - 没有缺点，也没有奇怪错误/异常的问题。